If I were to use CAN bus on the test fixture I'm planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface.

A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I'm not seeing this.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

søndag den 6. november 2022 kl. 14.34.38 UTC+1 skrev Ricky:
> If I were to use CAN bus on the test fixture I'm planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface.
>
> A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I'm not seeing this.
>

no point in using CAN if what you want it UART (over something like rs485/422)

CAN is similar to rs485 but "ORed" and with a fixed packet sizes, adresses,Acks, NAcks,CRC etc.

On Sunday, November 6, 2022 at 9:48:30 AM UTC-5, lang...@fonz.dk wrote:
> søndag den 6. november 2022 kl. 14.34.38 UTC+1 skrev Ricky:
> > If I were to use CAN bus on the test fixture I'm planning, I would need a USB cable that looks like a UART to the PC. Then I would need modules to mount on the test fixture boards that provide a UART like TTL interface.
> >
> > A quick survey finds lots of modules with wired connectors on both ends and units in metal boxes. I would need something that requires zero programming of the unit itself. I'm not seeing this.
> >
> no point in using CAN if what you want it UART (over something like rs485/422)
>
> CAN is similar to rs485 but "ORed" and with a fixed packet sizes, adresses,Acks, NAcks,CRC etc.

I would not care about the protocol on the CAN bus. I am assuming the interface to the PC would look like a UART. Or are the interface cards just low level hardware and the PC user code has to manage the low level protocol? By "look like a UART", I mean I simply pass data to an interface and receiver replies, without knowing, or caring about the details past that.

If a CAN bus interface can't do that, I definitely would not be interested. Even if it can do that, I would only be interested if it could provide some benefit. No one has explained what is better about CAN bus, they've just said I should use it.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

Ricky wrote:
> If I were to use CAN bus on the test fixture I'm planning, I would
> need a USB cable that looks like a UART to the PC. Then I would need
> modules to mount on the test fixture boards that provide a UART like
> TTL interface.
>

A Total Phase Komodo would provide a UART interface via USB. No need
for anything else. It is both small and has a plastic housing, if that
matters.

There are others. That is just the last one I used. I used it for plant
sim with a RasPi.

> A quick survey finds lots of modules with wired connectors on both
> ends and units in metal boxes. I would need something that requires
> zero programming of the unit itself. I'm not seeing this.
>

You're probably out of luck. The Komodo does come with software to
act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.

But when you say "test fixture" I think of nodes actively
participating and that requires programming.

--
Les Cargill

On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
> Ricky wrote:
> > If I were to use CAN bus on the test fixture I'm planning, I would
> > need a USB cable that looks like a UART to the PC. Then I would need
> > modules to mount on the test fixture boards that provide a UART like
> > TTL interface.
> >
> A Total Phase Komodo would provide a UART interface via USB. No need
> for anything else. It is both small and has a plastic housing, if that
> matters.
>
> There are others. That is just the last one I used. I used it for plant
> sim with a RasPi.
> > A quick survey finds lots of modules with wired connectors on both
> > ends and units in metal boxes. I would need something that requires
> > zero programming of the unit itself. I'm not seeing this.
> >
> You're probably out of luck. The Komodo does come with software to
> act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.
>
> But when you say "test fixture" I think of nodes actively
> participating and that requires programming.

The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters.

So command, response, command, response... all on a shared bus.

No one needs to worry with the test fixtures. That's taken care of, other than needing an interface for CAN. What is required for that?

The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that's all taken care of. I don't want to have to add anything that involves protocol of the CAN bus. That's why I say it needs to look like a UART to the PC. If that's so, I can use my existing software and not do extra work.

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

mandag den 21. november 2022 kl. 01.10.43 UTC+1 skrev Ricky:
> On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
> > Ricky wrote:
> > > If I were to use CAN bus on the test fixture I'm planning, I would
> > > need a USB cable that looks like a UART to the PC. Then I would need
> > > modules to mount on the test fixture boards that provide a UART like
> > > TTL interface.
> > >
> > A Total Phase Komodo would provide a UART interface via USB. No need
> > for anything else. It is both small and has a plastic housing, if that
> > matters.
> >
> > There are others. That is just the last one I used. I used it for plant
> > sim with a RasPi.
> > > A quick survey finds lots of modules with wired connectors on both
> > > ends and units in metal boxes. I would need something that requires
> > > zero programming of the unit itself. I'm not seeing this.
> > >
> > You're probably out of luck. The Komodo does come with software to
> > act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.
> >
> > But when you say "test fixture" I think of nodes actively
> > participating and that requires programming.
> The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters.
>
> So command, response, command, response... all on a shared bus.
>
> No one needs to worry with the test fixtures. That's taken care of, other than needing an interface for CAN. What is required for that?
>
> The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that's all taken care of. I don't want to have to add anything that involves protocol of the CAN bus. That's why I say it needs to look like a UART to the PC. If that's so, I can use my existing software and not do extra work.
>

if it needs to look like a uart don't use CAN, use a uart

Ricky wrote:
> On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
>> Ricky wrote:
>>> If I were to use CAN bus on the test fixture I'm planning, I
>>> would need a USB cable that looks like a UART to the PC. Then I
>>> would need modules to mount on the test fixture boards that
>>> provide a UART like TTL interface.
>>>
>> A Total Phase Komodo would provide a UART interface via USB. No
>> need for anything else. It is both small and has a plastic housing,
>> if that matters.
>>
>> There are others. That is just the last one I used. I used it for
>> plant sim with a RasPi.
>>> A quick survey finds lots of modules with wired connectors on
>>> both ends and units in metal boxes. I would need something that
>>> requires zero programming of the unit itself. I'm not seeing
>>> this.
>>>
>> You're probably out of luck. The Komodo does come with software to
>> act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.
>>
>> But when you say "test fixture" I think of nodes actively
>> participating and that requires programming.
>
> The current test fixture is a single board, testing a single UUT from
> a single PC. The new test fixture will have one PC talking at a rack
> of test fixtures, with each one having eight UUTs. The protocol of
> communications will be the same. Each message is a dozen or so
> characters, including an address of the target, and the command. The
> addressed target then responds with the information requested, or
> simply acknowledgement of the command, again, some doze or so
> characters.
>
> So command, response, command, response... all on a shared bus.
>
> No one needs to worry with the test fixtures. That's taken care of,
> other than needing an interface for CAN. What is required for that?
>

So at least J1939 is 29 bits of address and 16 bytes of payload. It is
not equivalent to a serial port. There will be a proprietary API to send
one PDU and to receive PDUs.

> The PC has a control program which will be modified to handle the UUT
> addressing. My concern is to not have to muck with programming in
> regards to anything about the CAN bus. The current interface is a
> simple UART, which is handled by system software and becomes two
> interfaces, one for sending data and one for receiving data. Again,
> that's all taken care of. I don't want to have to add anything that
> involves protocol of the CAN bus.

I suspect you will have to. It's not like 485 or 422.

> That's why I say it needs to look
> like a UART to the PC. If that's so, I can use my existing software
> and not do extra work.
>

You will need to adapt your existing commands to and onto the
proprietary API.

--
Les Cargill

On Sunday, November 20, 2022 at 7:16:48 PM UTC-5, lang...@fonz.dk wrote:
> mandag den 21. november 2022 kl. 01.10.43 UTC+1 skrev Ricky:
> > On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
> > > Ricky wrote:
> > > > If I were to use CAN bus on the test fixture I'm planning, I would
> > > > need a USB cable that looks like a UART to the PC. Then I would need
> > > > modules to mount on the test fixture boards that provide a UART like
> > > > TTL interface.
> > > >
> > > A Total Phase Komodo would provide a UART interface via USB. No need
> > > for anything else. It is both small and has a plastic housing, if that
> > > matters.
> > >
> > > There are others. That is just the last one I used. I used it for plant
> > > sim with a RasPi.
> > > > A quick survey finds lots of modules with wired connectors on both
> > > > ends and units in metal boxes. I would need something that requires
> > > > zero programming of the unit itself. I'm not seeing this.
> > > >
> > > You're probably out of luck. The Komodo does come with software to
> > > act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.
> > >
> > > But when you say "test fixture" I think of nodes actively
> > > participating and that requires programming.
> > The current test fixture is a single board, testing a single UUT from a single PC. The new test fixture will have one PC talking at a rack of test fixtures, with each one having eight UUTs. The protocol of communications will be the same. Each message is a dozen or so characters, including an address of the target, and the command. The addressed target then responds with the information requested, or simply acknowledgement of the command, again, some doze or so characters.
> >
> > So command, response, command, response... all on a shared bus.
> >
> > No one needs to worry with the test fixtures. That's taken care of, other than needing an interface for CAN. What is required for that?
> >
> > The PC has a control program which will be modified to handle the UUT addressing. My concern is to not have to muck with programming in regards to anything about the CAN bus. The current interface is a simple UART, which is handled by system software and becomes two interfaces, one for sending data and one for receiving data. Again, that's all taken care of. I don't want to have to add anything that involves protocol of the CAN bus. That's why I say it needs to look like a UART to the PC. If that's so, I can use my existing software and not do extra work.
> >
> if it needs to look like a uart don't use CAN, use a uart

What interface to the software does CAN use? I thought you were one of the people, who in another thread were suggesting I use CAN?

I just don't want to have to program a bunch of CAN protocol in my application. I would expect drivers to handle that. On the test fixture I would expect a chip to provide a UART on one side and CAN on the other.

This is not important. I see no reason why RS-422 or RS-485 would not be a good choice. It's actually the USB that presents the bottleneck from the polling rate.

--

Rick C.

-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209

On Sunday, November 20, 2022 at 7:32:37 PM UTC-5, Les Cargill wrote:
> Ricky wrote:
> > On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
> >> Ricky wrote:
> >>> If I were to use CAN bus on the test fixture I'm planning, I
> >>> would need a USB cable that looks like a UART to the PC. Then I
> >>> would need modules to mount on the test fixture boards that
> >>> provide a UART like TTL interface.
> >>>
> >> A Total Phase Komodo would provide a UART interface via USB. No
> >> need for anything else. It is both small and has a plastic housing,
> >> if that matters.
> >>
> >> There are others. That is just the last one I used. I used it for
> >> plant sim with a RasPi.
> >>> A quick survey finds lots of modules with wired connectors on
> >>> both ends and units in metal boxes. I would need something that
> >>> requires zero programming of the unit itself. I'm not seeing
> >>> this.
> >>>
> >> You're probably out of luck. The Komodo does come with software to
> >> act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.
> >>
> >> But when you say "test fixture" I think of nodes actively
> >> participating and that requires programming.
> >
> > The current test fixture is a single board, testing a single UUT from
> > a single PC. The new test fixture will have one PC talking at a rack
> > of test fixtures, with each one having eight UUTs. The protocol of
> > communications will be the same. Each message is a dozen or so
> > characters, including an address of the target, and the command. The
> > addressed target then responds with the information requested, or
> > simply acknowledgement of the command, again, some doze or so
> > characters.
> >
> > So command, response, command, response... all on a shared bus.
> >
> > No one needs to worry with the test fixtures. That's taken care of,
> > other than needing an interface for CAN. What is required for that?
> >
> So at least J1939 is 29 bits of address and 16 bytes of payload. It is
> not equivalent to a serial port. There will be a proprietary API to send
> one PDU and to receive PDUs.
> > The PC has a control program which will be modified to handle the UUT
> > addressing. My concern is to not have to muck with programming in
> > regards to anything about the CAN bus. The current interface is a
> > simple UART, which is handled by system software and becomes two
> > interfaces, one for sending data and one for receiving data. Again,
> > that's all taken care of. I don't want to have to add anything that
> > involves protocol of the CAN bus.
> I suspect you will have to. It's not like 485 or 422.
> > That's why I say it needs to look
> > like a UART to the PC. If that's so, I can use my existing software
> > and not do extra work.
> >
> You will need to adapt your existing commands to and onto the
> proprietary API.

Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.

--

Rick C.

+- Get 1,000 miles of free Supercharging
+- Tesla referral code - https://ts.la/richard11209

On Sun, 20 Nov 2022 16:34:02 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>What interface to the software does CAN use?

The CAN frame consists of two main fields:
* CAN identifier (11 or 29 bits)
* Payload (0-64 bits, 0-8 bytes)

Especially with 29 bit CAN-ID you could allocate a few bits for slave
address and a few bits for function code. In the simplest case the
interface would contain a 32 bit CAN-ID ad an 8 bit payload for both
reading and writing.

The nice thing about CAN is that the hardware does the arbitration
between frames based on the CAN-ID. Thus, you can send out broadcast
reads and collect all responses. You could also send out requests to
multiple slow devices at once and collect the responses room diff rent
devices when ready, without having to worry about collision handling.

he problem with half-duplex RS-485 is the line turnaround delays and
waiting for slave responses, which quickly degrades throughput at high
line speeds. On CAN the line mutilation can be quite high and at 1
MBit/s the throughput can be better than on RS-485 at higher speeds.

On Monday, November 21, 2022 at 1:39:45 AM UTC-5, upsid...@downunder.com wrote:
> On Sun, 20 Nov 2022 16:34:02 -0800 (PST), Ricky
> <gnuarm.del...@gmail.com> wrote:
>
> >What interface to the software does CAN use?
> The CAN frame consists of two main fields:
> * CAN identifier (11 or 29 bits)
> * Payload (0-64 bits, 0-8 bytes)
>
> Especially with 29 bit CAN-ID you could allocate a few bits for slave
> address and a few bits for function code. In the simplest case the
> interface would contain a 32 bit CAN-ID ad an 8 bit payload for both
> reading and writing.
>
> The nice thing about CAN is that the hardware does the arbitration
> between frames based on the CAN-ID. Thus, you can send out broadcast
> reads and collect all responses. You could also send out requests to
> multiple slow devices at once and collect the responses room diff rent
> devices when ready, without having to worry about collision handling.
>
> he problem with half-duplex RS-485 is the line turnaround delays and
> waiting for slave responses, which quickly degrades throughput at high
> line speeds. On CAN the line mutilation can be quite high and at 1
> MBit/s the throughput can be better than on RS-485 at higher speeds.

I have no interest in getting involved in the CAN bus protocol. To me it's something that needs to be invisible, a way to transport characters, in the same way I use a serial port under Windows.

Your description of RS-485 is not important to me. You have either not been part of the previous conversations where I described the use case, and some details of the hardware, or you would realize that the issues you present have no relevance to my design. The speed limitation has nothing to do with the RS-485 or RS-422 buses. The limitation is in the 8 kHz polling rate, which sets the limit on the number of messages which can be handled on the USB interface. The limit is messages, not bits or characters.

Your post presents all the reasons why I have no interest in using CAN. I don't want to even be aware of the messages on the CAN bus. The PC should have software that hides all that and presents a port like a COM port, in fact, it should emulate a COM port. On the slave end, I would want a chip, or better, a module that provides a CAN bus interface with a virtual UART interface on the other side, or a serial port would suffice. The FPGA already has the UART in it. BTW, there are no slow devices on the bus. Every device responds within fractions of a microsecond, depending on the baud rate setting.

Right now, the test fixture talks to the PC through an RS-232 USB cable. I'm looking for something that can take it's place pretty much without software changes. So far, everyone talks about programming though an API, which is of no interest to me.

--

Rick C.

++ Get 1,000 miles of free Supercharging
++ Tesla referral code - https://ts.la/richard11209

On 11/20/2022 7:37 PM, Ricky wrote:
> On Sunday, November 20, 2022 at 7:32:37 PM UTC-5, Les Cargill wrote:
>> Ricky wrote:
>>> On Sunday, November 20, 2022 at 4:22:54 PM UTC-5, Les Cargill wrote:
>>>> Ricky wrote:
>>>>> If I were to use CAN bus on the test fixture I'm planning, I
>>>>> would need a USB cable that looks like a UART to the PC. Then I
>>>>> would need modules to mount on the test fixture boards that
>>>>> provide a UART like TTL interface.
>>>>>
>>>> A Total Phase Komodo would provide a UART interface via USB. No
>>>> need for anything else. It is both small and has a plastic housing,
>>>> if that matters.
>>>>
>>>> There are others. That is just the last one I used. I used it for
>>>> plant sim with a RasPi.
>>>>> A quick survey finds lots of modules with wired connectors on
>>>>> both ends and units in metal boxes. I would need something that
>>>>> requires zero programming of the unit itself. I'm not seeing
>>>>> this.
>>>>>
>>>> You're probably out of luck. The Komodo does come with software to
>>>> act as a CAN-alyzer for monitoring, a "Wireshark" for CAN.
>>>>
>>>> But when you say "test fixture" I think of nodes actively
>>>> participating and that requires programming.
>>>
>>> The current test fixture is a single board, testing a single UUT from
>>> a single PC. The new test fixture will have one PC talking at a rack
>>> of test fixtures, with each one having eight UUTs. The protocol of
>>> communications will be the same. Each message is a dozen or so
>>> characters, including an address of the target, and the command. The
>>> addressed target then responds with the information requested, or
>>> simply acknowledgement of the command, again, some doze or so
>>> characters.
>>>
>>> So command, response, command, response... all on a shared bus.
>>>
>>> No one needs to worry with the test fixtures. That's taken care of,
>>> other than needing an interface for CAN. What is required for that?
>>>
>> So at least J1939 is 29 bits of address and 16 bytes of payload. It is
>> not equivalent to a serial port. There will be a proprietary API to send
>> one PDU and to receive PDUs.
>>> The PC has a control program which will be modified to handle the UUT
>>> addressing. My concern is to not have to muck with programming in
>>> regards to anything about the CAN bus. The current interface is a
>>> simple UART, which is handled by system software and becomes two
>>> interfaces, one for sending data and one for receiving data. Again,
>>> that's all taken care of. I don't want to have to add anything that
>>> involves protocol of the CAN bus.
>> I suspect you will have to. It's not like 485 or 422.
>>> That's why I say it needs to look
>>> like a UART to the PC. If that's so, I can use my existing software
>>> and not do extra work.
>>>
>> You will need to adapt your existing commands to and onto the
>> proprietary API.
>
> Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.
>

+1

--
Dogs make me happy. Humans make my head hurt.

On 21/11/2022 00:37, Ricky wrote:

> Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.
>

What was wrong with just diodes on the UUT Tx with a pull-down on the PC
Rx, possibly with buffering on the PC Tx?

RS232 idles -ve, and AIUI, only 1 UUT can talk at a time and they don't
respond if not addressed.

--
Cheers
Clive

On Monday, November 21, 2022 at 11:48:51 AM UTC-5, Clive Arthur wrote:
> On 21/11/2022 00:37, Ricky wrote:
>
> > Ok, then CAN just went into the waste bucket for this project. I see no reason to explore complexity for something that is fundamentally simple.
> >
> What was wrong with just diodes on the UUT Tx with a pull-down on the PC
> Rx, possibly with buffering on the PC Tx?
>
> RS232 idles -ve, and AIUI, only 1 UUT can talk at a time and they don't
> respond if not addressed.

This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me. I can't think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that's not an advantage.

I had pretty well settled on an RS-422 based approach with the master the only talker on one pair, and the addressed slave replying on the other pair. Because of the back and forth message protocol, there is no worry with collisions unless someone loses their mind and clobbers the bus. The only issue I can see is the USB limitation of of high speed polling being 8 kHz which limits the message rate to a single UUT (with 256 in the system) to 16 commands per second. That will limit the testing rate, but since the audio tests take a few seconds anyway, I think all in all, it will be a foot race as to which will take the longest. So it doesn't look like that is a significant limitation.

So I'm happy with RS-422. If I want to get fancy, I could adjust the protocol so messages can overlap, in the sense that the master can address multiple slaves without waiting for any one to respond. The slaves will need to manage their collisions, but that should not be an issue, since they can reply within a fraction of a microsecond. By the time the second slave has received a command, the first slave will be nearly finished with its reply and the second slave only needs to monitor for the end of message (/n I believe). The only problem is if there are too many overlapped at one time, multiple slaves might be waiting for the end of a response to start its own response and two start at the same time. To sort that, either some delays need to be added to the master, or the slaves need to be aware of who the master is talking to and who has replied. Too much complexity, even if it's not hard to make work. At 1 minute per test on 256 units, this will be around 512 times faster than a human running the tests, so I think we are good.

The real gold in this is the handling of boards are reduced. We have been plugging a board into the test fixture to test, then plug it into the burn in chassis, the the test fixture again. The connectors are pretty much crap for such use and we have a hard time training people to be gentle enough with them. On removal, the narrow board twists in the fingers, bending/braking pins on the test fixture, and breaking connectors on the UUT. Cutting the insertions and removals to one, with 1,000 tests in between, will go a long way to improving our throughput.

I think I got a bit off topic. My point is, the RS-232 approach doesn't seem to have any advantage over RS-422 and multi-point operation with RS-422 is well known and well established. I only was asking about CAN because a couple of people said it was a good way to go for this. Now that I have more info, I'm not so sure.

--

Rick C.

--- Get 1,000 miles of free Supercharging
--- Tesla referral code - https://ts.la/richard11209

On 22/11/2022 00:36, Ricky wrote:

<snip>

> This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me. I can't think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that's not an advantage.
>

The advantage is that you could have been up and running for the last
couple of weeks with pretty much your existing hardware AIUI. The main
disadvantage is the chance of a faulty UUT buggering up the whole deal.
Don't let perfect be the enemy of good.

--
Cheers
Clive

On Tuesday, November 22, 2022 at 4:51:12 AM UTC-4, Clive Arthur wrote:
> On 22/11/2022 00:36, Ricky wrote:
>
> <snip>
> > This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me. I can't think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that's not an advantage.
> >
> The advantage is that you could have been up and running for the last
> couple of weeks with pretty much your existing hardware AIUI. The main
> disadvantage is the chance of a faulty UUT buggering up the whole deal.
> Don't let perfect be the enemy of good.

How could I have been up for the last couple of weeks? The new test fixtures aren't even designed yet. I'm not sure what you are talking about with "a faulty UUT buggering up the whole deal"? The UUT is not on the bus. The test fixture is. The purpose of the test fixture is to test the UUTs. I expect the procedure will be to install 8 UUTs onto a test fixture, perform one round of testing to determine if any units fail. Failing units are replaced until all 8 work. Install the test fixture into the chassis. Rinse, lather, repeat, until the test chassis is fully of test fixtures with UUTs that initially pass test. They are then left to burn in over night. The next morning the results will be checked for failures. UUTs without failures will be labeled and shipped with the results of the final test saved as a record.

What are you picturing, exactly? I don't see how a tristated RS-232 interface is any different from an RS-422 interface except that the RS-232 interface won't run as fast and is not specified to actually work well, given the pull down resistor required.

What am I missing?

--

Rick C.

--+ Get 1,000 miles of free Supercharging
--+ Tesla referral code - https://ts.la/richard11209

On Mon, 21 Nov 2022 16:36:31 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me.

So you can afford to buy one or two table top PCs and use directly
some PCIe RS-422/485 cards which are available at least with 1 to 8
serial lines. You can use these cards directly without messing up with
USB.

If you insist on using USB, why don't you go with USB from end to end
and skip the RS-232/422/485 all together ? Use two or three USB hubs
in series to branch to all slaves.
>I can't think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that's not an advantage.

The RS-232 diode trick will work with a few slaves on the same table,
but the noise margins will be deteriorated.
>I had pretty well settled on an RS-422 based approach with the master the only talker on one pair, and the addressed slave replying on the other pair.

To be pedantic, the standard calls this 4-wire RS-485.
The nice thing is that there are good pauses in the Master Tx pair
(when a slave transmits on the other pair). Thus you can run even
Modbus without being too accurate with timing. With 2-wire RS-485, the
slaves must adhere to the timing specification quite accurately.

> Because of the back and forth message protocol, there is no worry with collisions unless someone loses their mind and clobbers the bus.
>The only issue I can see is the USB limitation of of high speed polling being 8 kHz which limits the message rate to a single UUT (with 256 in the system) to 16 commands per second. That will limit the testing rate, but since the audio tests take a few seconds anyway, I think all in all, it will be a foot race as to which will take the longest. So it doesn't look like that is a significant limitation.

8 kHz polling rate with Windows ?? You must be joking.

>So I'm happy with RS-422. If I want to get fancy, I could adjust the protocol so messages can overlap, in the sense that the master can address multiple slaves without waiting for any one to respond. The slaves will need to manage their collisions, but that should not be an issue, since they can reply within a fraction of a microsecond. By the time the second slave has received a command, the first slave will be nearly finished with its reply and the second slave only needs to monitor for the end of message (/n I believe). The only problem is if there are too many overlapped at one time, multiple slaves might be waiting for the end of a response to start its own response and two start at the same time. To sort that, either some delays need to be added to the master, or the slaves need to be aware of who the master is talking to and who has replied. Too much complexity, even if it's not hard to make work. At 1 minute per test on 256 units, this will be around 512 times faster
>than a human running the tests, so I think we are good.

In 4-wire RS-485 the slave only hears the master, they do not hear the
transmission by other slaves. Use 2-wire RS-485 if each slave must
listen to master _and_ other slaves.

On Thursday, November 24, 2022 at 2:36:22 PM UTC-4, upsid...@downunder.com wrote:
> On Mon, 21 Nov 2022 16:36:31 -0800 (PST), Ricky
> <gnuarm.del...@gmail.com> wrote:
>
> >This is a rig that will test millions of dollars worth of boards, providing millions of dollars of profit to me.
> So you can afford to buy one or two table top PCs and use directly
> some PCIe RS-422/485 cards which are available at least with 1 to 8
> serial lines. You can use these cards directly without messing up with
> USB.

Yeah, that's an option. I don't know if that is important to do. While the USB limitations create a ceiling for the throughput, I don't know that it is a problem as yet, as long as the USB used is high-speed. So the jury is still out on the need for faster operation.

> If you insist on using USB, why don't you go with USB from end to end
> and skip the RS-232/422/485 all together ? Use two or three USB hubs
> in series to branch to all slaves.

I've never had much success in cascading hubs. One hub works fine, but serial hubs seem to have issues with various devices. I have zero interest in using a flaky USB distribution. Since I currently have no need and still don't know if that would fix the problem, I'm not going to give this further consideration at this time.

> >I can't think of a single advantage of using RS-232 with diodes, other than possibly a significantly reduced data rate. Oh, wait, that's not an advantage.
> The RS-232 diode trick will work with a few slaves on the same table,
> but the noise margins will be deteriorated.
> >I had pretty well settled on an RS-422 based approach with the master the only talker on one pair, and the addressed slave replying on the other pair.
> To be pedantic, the standard calls this 4-wire RS-485.

Can you refer me to this standard? I've not seen this in the many sites I've visited regarding the approach. Looking it up, it seems to be discussed, but is not a part of any standard.

> The nice thing is that there are good pauses in the Master Tx pair
> (when a slave transmits on the other pair). Thus you can run even
> Modbus without being too accurate with timing. With 2-wire RS-485, the
> slaves must adhere to the timing specification quite accurately.

Hmmm... I'm not following this, but I doubt Modbus offers any advantages over RS-422/485 that are relevant to me, so I don't think I need to pursue this.

> > Because of the back and forth message protocol, there is no worry with collisions unless someone loses their mind and clobbers the bus.
> >The only issue I can see is the USB limitation of of high speed polling being 8 kHz which limits the message rate to a single UUT (with 256 in the system) to 16 commands per second. That will limit the testing rate, but since the audio tests take a few seconds anyway, I think all in all, it will be a foot race as to which will take the longest. So it doesn't look like that is a significant limitation.
> 8 kHz polling rate with Windows ?? You must be joking.

I would never joke with you. I know better.

> >So I'm happy with RS-422. If I want to get fancy, I could adjust the protocol so messages can overlap, in the sense that the master can address multiple slaves without waiting for any one to respond. The slaves will need to manage their collisions, but that should not be an issue, since they can reply within a fraction of a microsecond. By the time the second slave has received a command, the first slave will be nearly finished with its reply and the second slave only needs to monitor for the end of message (/n I believe). The only problem is if there are too many overlapped at one time, multiple slaves might be waiting for the end of a response to start its own response and two start at the same time. To sort that, either some delays need to be added to the master, or the slaves need to be aware of who the master is talking to and who has replied. Too much complexity, even if it's not hard to make work. At 1 minute per test on 256 units, this will be around 512 times faster
> >than a human running the tests, so I think we are good.
> In 4-wire RS-485 the slave only hears the master, they do not hear the
> transmission by other slaves. Use 2-wire RS-485 if each slave must
> listen to master _and_ other slaves.

Ok, thank you.

--

Rick C.

-+- Get 1,000 miles of free Supercharging
-+- Tesla referral code - https://ts.la/richard11209

On Thu, 24 Nov 2022 12:59:53 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>On Thursday, November 24, 2022 at 2:36:22 PM UTC-4, upsid...@downunder.com wrote:

>> To be pedantic, the standard calls this 4-wire RS-485.
>
>Can you refer me to this standard?

I read it from the official RS-485 standard document from the 1980's.
Of course it was on paper. This standard also talks about "fail-safe"
termination, in which the quotes are part of the standard :-).

> I've not seen this in the many sites I've visited regarding the approach.

Did you study the official TIA RS-485 standard document ?

> Looking it up, it seems to be discussed, but is not a part of any standard.

In many papers there are references to full-duplex RS-485 using two
pairs

>> The nice thing is that there are good pauses in the Master Tx pair
>> (when a slave transmits on the other pair). Thus you can run even
>> Modbus without being too accurate with timing. With 2-wire RS-485, the
>> slaves must adhere to the timing specification quite accurately.
>
>Hmmm... I'm not following this, but I doubt Modbus offers any advantages over RS-422/485 that are relevant to me, so I don't think I need to pursue this.

Modbus is a software protocol typically using RS-xxx hardware. The
Modbus RTU version is notorious for the timing requirements. It was
created before RS-485 standard was finalized and apparently used some
RS-232 diode tricks, i.e. had to avoid reflections on a serial bus
with impedance missmatches.. Also RS-485 "fail-safe" solved some
problems due to a floating tri-state bus.

>
>> > Because of the back and forth message protocol, there is no worry with collisions unless someone loses their mind and clobbers the bus.
>> >The only issue I can see is the USB limitation of of high speed polling being 8 kHz which limits the message rate to a single UUT (with 256 in the system) to 16 commands per second. That will limit the testing rate, but since the audio tests take a few seconds anyway, I think all in all, it will be a foot race as to which will take the longest. So it doesn't look like that is a significant limitation.
>> 8 kHz polling rate with Windows ?? You must be joking.
>
>I would never joke with you. I know better.

In Windows user mode timing directives have only 1 ms timing
resolution (when multimedis timers enabled). To get 8 kHz scan rate
(0.125 ms), you are going to use a kernel mode driver that at least
sends out the request and receives the response (possibly handling
retransmissions) before returning to user mode.

Actually you would need a WriteReadFile system cal that sends out
multiple requests collects multiple read responses into an other
buffer and only return to user mode after the response from the last
request has been received.

On Friday, November 25, 2022 at 6:36:55 AM UTC-4, upsid...@downunder.com wrote:
> On Thu, 24 Nov 2022 12:59:53 -0800 (PST), Ricky
> <gnuarm.del...@gmail.com> wrote:
>
> >On Thursday, November 24, 2022 at 2:36:22 PM UTC-4, upsid...@downunder.com wrote:
>
> >> To be pedantic, the standard calls this 4-wire RS-485.
> >
> >Can you refer me to this standard?
> I read it from the official RS-485 standard document from the 1980's.
> Of course it was on paper. This standard also talks about "fail-safe"
> termination, in which the quotes are part of the standard :-).
> > I've not seen this in the many sites I've visited regarding the approach.
> Did you study the official TIA RS-485 standard document ?

Can you provide a link? I've seen many sites that quote significant portions of the standard an none mention this.

> > Looking it up, it seems to be discussed, but is not a part of any standard.
> In many papers there are references to full-duplex RS-485 using two
> pairs

Yup

> >> The nice thing is that there are good pauses in the Master Tx pair
> >> (when a slave transmits on the other pair). Thus you can run even
> >> Modbus without being too accurate with timing. With 2-wire RS-485, the
> >> slaves must adhere to the timing specification quite accurately.
> >
> >Hmmm... I'm not following this, but I doubt Modbus offers any advantages over RS-422/485 that are relevant to me, so I don't think I need to pursue this.
> Modbus is a software protocol typically using RS-xxx hardware. The
> Modbus RTU version is notorious for the timing requirements. It was
> created before RS-485 standard was finalized and apparently used some
> RS-232 diode tricks, i.e. had to avoid reflections on a serial bus
> with impedance missmatches.. Also RS-485 "fail-safe" solved some
> problems due to a floating tri-state bus.

What does an RTU do?

> >> > Because of the back and forth message protocol, there is no worry with collisions unless someone loses their mind and clobbers the bus.
> >> >The only issue I can see is the USB limitation of of high speed polling being 8 kHz which limits the message rate to a single UUT (with 256 in the system) to 16 commands per second. That will limit the testing rate, but since the audio tests take a few seconds anyway, I think all in all, it will be a foot race as to which will take the longest. So it doesn't look like that is a significant limitation.
> >> 8 kHz polling rate with Windows ?? You must be joking.
> >
> >I would never joke with you. I know better.
> In Windows user mode timing directives have only 1 ms timing
> resolution (when multimedis timers enabled). To get 8 kHz scan rate
> (0.125 ms), you are going to use a kernel mode driver that at least
> sends out the request and receives the response (possibly handling
> retransmissions) before returning to user mode.
>
> Actually you would need a WriteReadFile system cal that sends out
> multiple requests collects multiple read responses into an other
> buffer and only return to user mode after the response from the last
> request has been received.

That's all stuff behind the scenes. My software interface is a simple COM port. I don't care how they do it, just that it happens.

--

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209

On Fri, 25 Nov 2022 14:43:36 -0800 (PST), Ricky
<gnuarm.deletethisbit@gmail.com> wrote:

>On Friday, November 25, 2022 at 6:36:55 AM UTC-4, upsid...@downunder.com wrote:
>> On Thu, 24 Nov 2022 12:59:53 -0800 (PST), Ricky
>> <gnuarm.del...@gmail.com> wrote:
>>
>> >On Thursday, November 24, 2022 at 2:36:22 PM UTC-4, upsid...@downunder.com wrote:
>>
>> >> To be pedantic, the standard calls this 4-wire RS-485.
>> >
>> >Can you refer me to this standard?
>> I read it from the official RS-485 standard document from the 1980's.
>> Of course it was on paper. This standard also talks about "fail-safe"
>> termination, in which the quotes are part of the standard :-).
>> > I've not seen this in the many sites I've visited regarding the approach.
>> Did you study the official TIA RS-485 standard document ?
>
>Can you provide a link? I've seen many sites that quote significant portions of the standard an none mention this.

Standard organizations make their living by selling individual copies
of their standards. To get a full text copy of a standard you may have
to pay for copy (typically a few hundred dollars). You may have to
figure out which American standard organization has the original
version and pay for it.

>> >> The nice thing is that there are good pauses in the Master Tx pair
>> >> (when a slave transmits on the other pair). Thus you can run even
>> >> Modbus without being too accurate with timing. With 2-wire RS-485, the
>> >> slaves must adhere to the timing specification quite accurately.
>> >
>> >Hmmm... I'm not following this, but I doubt Modbus offers any advantages over RS-422/485 that are relevant to me, so I don't think I need to pursue this.
>> Modbus is a software protocol typically using RS-xxx hardware. The
>> Modbus RTU version is notorious for the timing requirements. It was
>> created before RS-485 standard was finalized and apparently used some
>> RS-232 diode tricks, i.e. had to avoid reflections on a serial bus
>> with impedance missmatches.. Also RS-485 "fail-safe" solved some
>> problems due to a floating tri-state bus.
>
>What does an RTU do?

https://en.wikipedia.org/wiki/Remote_terminal_unit

There are three versions of Modbus:

* Modbus RTU: binary version with nasty timing requirements
* Modbus ASCII: with printable hexadecimal characters ending by <CR>
* Nidbus/TCP: binary protocol with extra header over TCP/IP