CANBUS Tx/Rx with data length > 8 bytes

On 02.12.2015 г. 00:11, Hans-Bernhard Bröker wrote:
> Am 29.11.2015 um 22:23 schrieb Dimiter_Popoff:
>
>> It is not about the cable being round, it is about the cabling length.
>> With a coaxial cable it can be nodes_count times shorter, just a single
>> cable running through all the nodes.
>
> Whether or not that's actually shorter depends a whole lot on where all
> those nodes are, and where cables can go without being in the way.
>
> In somewhat a typical office environment, if you want it to be even
> remotely flexible, coaxial cable tends to have to run from some boundary
> (wall, floor, ceiling) to every node _and_back_again_.
>
> And then of course there's the old one-fault-kills-it-all issue. Finding
> out which of 50 "T"s, spread over 10 offices, is the flaky one is really
> no fun at all.
>

All of this is true of course, just like it is true that a single cable
is the better choice on some other occasions. May be nowadays it is not
just Ethernet though, not 10base2 etc. at least, this wastes cable
resources massively. For example on the street where I am now a 75 Ohm
coaxial cable provides cable TV to all houses, Internet (I get 50 Mbps
down/something like 4 Mbps up, could opt for twice that if I needed it).

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

David Brown wrote:
> On 01/12/15 06:44, Les Cargill wrote:
>> upsidedown@downunder.com wrote:
>>> On Sun, 29 Nov 2015 09:57:52 -0600, Les Cargill
>>> <lcargill99@comcast.com> wrote:
>>>
>>>>>     You can use standard networking and TCP/IP for ease of development
>>>>> (Modbus over TCP/IP handles pretty much everything you need for a
>>>>> typical fieldbus application, and you can add other protocols such as
>>>>> TFTP for larger transfers).
>>>>
>>>> Not a big fan of MODBUS over TCP. It's okay.
>>>
>>> Run Modbus RTU or Modbus/TCP frames in UDP frames.
>>>
>>
>> I haven't tried that. It's full duplex? The turnaround times
>> are what kills MODBUS RTU.
>>
>
> That question makes no sense - MODBUS is a master/slave or
> question/response protocol.  The master sends a question, and the slave
> cannot send the response before the question arrives, so it is
> necessarily half-duplex.
>


If you asynchrously send over Ethernet, then gather responses with a 
select() or epoll() loop which then feeds a
state machine per MODBUS address, the line
itself need never be waited on.

With RTU over 2-wire 485/422/whatever it's inherently
half duplex, and you lose the channel whilst waiting
on responses.

> But being Ethernet, the connection itself is full duplex (normally).
> That means you have have multiple master-slave connections and transfers
> going on at the same time.  And since you don't have to have a single
> bus master at a time, it is quite possible to have multiple Modbus
> masters on the same network at the same time.
>
> Using UDP reduces the packet overhead a little in comparison to UDP (you
> don't need ACK's and connection handshaking), but typically it makes
> very little real-world difference.  And TCP/IP is /far/ easier if you
> are doing something beyond a simple closed network, such as routing
> traffic around, passing it through firewalls, VPNs, wireless bridges, etc.
>

This is true until somebody pulls a wire out of a port :)

>
> And turnaround times are /not/ an issue for carefully implemented MODBUS
> RTU.  Unless you have very special bus hardware, the RS485 bus can be
> turned around in a bittime or two.  The issue here is how fast the
> master can guarantee to switch off its bus drivers - that gives the
> minimum latency before the slave can start its reply.

So I have seen wait times, including bit times, of 30+ *milliseconds*
with some MODBUS implementations ( say @ 38400 BPS for a three-register 
read or write ) . 10-15 is more typical.

You're constrained to 31 nodes per wire pair for a reason.

> And of course
> slave reaction time and latency can be an issue.

Right!

> So while it is common
> to have long delays before slave replies, in order to handle slow
> masters, it is certainly not necessary.
>
>
>

-- 
Les Cargill

On Tue, 1 Dec 2015 23:47:43 -0600, Les Cargill
<lcargill99@comcast.com> wrote:

>> And turnaround times are /not/ an issue for carefully implemented MODBUS
>> RTU.  Unless you have very special bus hardware, the RS485 bus can be
>> turned around in a bittime or two.  The issue here is how fast the
>> master can guarantee to switch off its bus drivers - that gives the
>> minimum latency before the slave can start its reply.
>
>So I have seen wait times, including bit times, of 30+ *milliseconds*
>with some MODBUS implementations ( say @ 38400 BPS for a three-register 
>read or write ) . 10-15 is more typical.
>
>You're constrained to 31 nodes per wire pair for a reason.

That 30+ ms sounds like the internal cycle time of the PLC (slave).
Typically a PLC reads inputs at the beginning of the loop, does the
processing and then writes the final outputs at the end of the loop.

If serial line requests are processed at the same time as other inputs
at the beginning of the loop and responses sent back to the serial
line at the end of the loop, this would give such 30+ ms latencies.

The other alternative is to use a process image, into which the PLC
writes output values. A serial line process (or just an interrupt
service routine) receives the request from the line, copies data from
the process image to the response and sends back the response in well
below a millisecond. 

Commands to the PLC are written into the process image and at some
later time the main PLC loop gets the command from the process image
and replies immediately to the master. Of course, the master only
knows that the command was delivered to the process image, it doesn't
know if the main PLC main loop is even running.

On 02/12/15 06:47, Les Cargill wrote:
> David Brown wrote:
>> On 01/12/15 06:44, Les Cargill wrote:
>>> upsidedown@downunder.com wrote:
>>>> On Sun, 29 Nov 2015 09:57:52 -0600, Les Cargill
>>>> <lcargill99@comcast.com> wrote:
>>>>
>>>>>>     You can use standard networking and TCP/IP for ease of
>>>>>> development
>>>>>> (Modbus over TCP/IP handles pretty much everything you need for a
>>>>>> typical fieldbus application, and you can add other protocols such as
>>>>>> TFTP for larger transfers).
>>>>>
>>>>> Not a big fan of MODBUS over TCP. It's okay.
>>>>
>>>> Run Modbus RTU or Modbus/TCP frames in UDP frames.
>>>>
>>>
>>> I haven't tried that. It's full duplex? The turnaround times
>>> are what kills MODBUS RTU.
>>>
>>
>> That question makes no sense - MODBUS is a master/slave or
>> question/response protocol.  The master sends a question, and the slave
>> cannot send the response before the question arrives, so it is
>> necessarily half-duplex.
>>
> 
> 
> If you asynchrously send over Ethernet, then gather responses with a
> select() or epoll() loop which then feeds a
> state machine per MODBUS address, the line
> itself need never be waited on.

I see what you mean now.  If you are accessing multiple slaves over the
same Ethernet network you can do this to get better use of the
bandwidth.  So your Ethernet connection is full duplex, even though each
individual Modbus connection is half duplex.

> 
> With RTU over 2-wire 485/422/whatever it's inherently
> half duplex, and you lose the channel whilst waiting
> on responses.

The bus turnaround itself is not an major part of the delay - the delays
are usually while waiting for the slave (server) to put together a
response.  With RS-485, you can't do anything else during that delay,
but with Ethernet you can communicate with other slaves while waiting.
(The same applies to CAN communication.)

> 
>> But being Ethernet, the connection itself is full duplex (normally).
>> That means you have have multiple master-slave connections and transfers
>> going on at the same time.  And since you don't have to have a single
>> bus master at a time, it is quite possible to have multiple Modbus
>> masters on the same network at the same time.
>>
>> Using UDP reduces the packet overhead a little in comparison to UDP (you
>> don't need ACK's and connection handshaking), but typically it makes
>> very little real-world difference.  And TCP/IP is /far/ easier if you
>> are doing something beyond a simple closed network, such as routing
>> traffic around, passing it through firewalls, VPNs, wireless bridges,
>> etc.
>>
> 
> This is true until somebody pulls a wire out of a port :)

/Every/ network system will fail when someone pulls out wires!

> 
>>
>> And turnaround times are /not/ an issue for carefully implemented MODBUS
>> RTU.  Unless you have very special bus hardware, the RS485 bus can be
>> turned around in a bittime or two.  The issue here is how fast the
>> master can guarantee to switch off its bus drivers - that gives the
>> minimum latency before the slave can start its reply.
> 
> So I have seen wait times, including bit times, of 30+ *milliseconds*
> with some MODBUS implementations ( say @ 38400 BPS for a three-register
> read or write ) . 10-15 is more typical.

That is delays in the software in the server, not bus turnaround.  The
same applies in Modbus over Ethernet, if the server software is equally
slow - the difference (as noted above) is that you can communicate with
other servers while waiting.

When I have made Modbus 485 servers, the delays have generally been a
small fraction of a millisecond - it's just a matter of writing software
that can respond quickly.

> 
> You're constrained to 31 nodes per wire pair for a reason.

You are indeed constrained to 31 nodes per bus for a reason - but that
reason is electrical bus load and capacitance, not timing, turnaround
delays or latencies.  It is part of the RS-485 bus standard which gives
limits on combinations of bus lengths, speeds, cable loads and the
number of nodes assuming a "standard" load capacitance.  You can also
get half-load drivers and have twice as many on a single bus while
remaining in spec, or even quarter load drivers and have four times as
many.  Or you can use out-of-spec combinations (such as slower and
shorter buses) with more nodes.

> 
>> And of course
>> slave reaction time and latency can be an issue.
> 
> Right!

That is the key point if you are seeing 30 ms delays.

> 
>> So while it is common
>> to have long delays before slave replies, in order to handle slow
>> masters, it is certainly not necessary.
>>
>>
>>
> 

upsidedown@downunder.com wrote:
> On Tue, 1 Dec 2015 23:47:43 -0600, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>>> And turnaround times are /not/ an issue for carefully implemented MODBUS
>>> RTU.  Unless you have very special bus hardware, the RS485 bus can be
>>> turned around in a bittime or two.  The issue here is how fast the
>>> master can guarantee to switch off its bus drivers - that gives the
>>> minimum latency before the slave can start its reply.
>>
>> So I have seen wait times, including bit times, of 30+ *milliseconds*
>> with some MODBUS implementations ( say @ 38400 BPS for a three-register
>> read or write ) . 10-15 is more typical.
>>
>> You're constrained to 31 nodes per wire pair for a reason.
>
> That 30+ ms sounds like the internal cycle time of the PLC (slave).

Yep. 10 for read, 10 for processing & 10 for sending is
how I read it.

> Typically a PLC reads inputs at the beginning of the loop, does the
> processing and then writes the final outputs at the end of the loop.
>

This wasn't a PLC; it was a relay... thingy.

> If serial line requests are processed at the same time as other inputs
> at the beginning of the loop and responses sent back to the serial
> line at the end of the loop, this would give such 30+ ms latencies.
>
> The other alternative is to use a process image, into which the PLC
> writes output values. A serial line process (or just an interrupt
> service routine) receives the request from the line, copies data from
> the process image to the response and sends back the response in well
> below a millisecond.
>

I have managed to avoid PLCs so far.

> Commands to the PLC are written into the process image and at some
> later time the main PLC loop gets the command from the process image
> and replies immediately to the master. Of course, the master only
> knows that the command was delivered to the process image, it doesn't
> know if the main PLC main loop is even running.
>

-- 
Les Cargill

David Brown wrote:
> On 02/12/15 06:47, Les Cargill wrote:
>> David Brown wrote:
>>> On 01/12/15 06:44, Les Cargill wrote:
>>>> upsidedown@downunder.com wrote:
>>>>> On Sun, 29 Nov 2015 09:57:52 -0600, Les Cargill
>>>>> <lcargill99@comcast.com> wrote:
>>>>>
>>>>>>>      You can use standard networking and TCP/IP for ease of
>>>>>>> development
>>>>>>> (Modbus over TCP/IP handles pretty much everything you need for a
>>>>>>> typical fieldbus application, and you can add other protocols such as
>>>>>>> TFTP for larger transfers).
>>>>>>
>>>>>> Not a big fan of MODBUS over TCP. It's okay.
>>>>>
>>>>> Run Modbus RTU or Modbus/TCP frames in UDP frames.
>>>>>
>>>>
>>>> I haven't tried that. It's full duplex? The turnaround times
>>>> are what kills MODBUS RTU.
>>>>
>>>
>>> That question makes no sense - MODBUS is a master/slave or
>>> question/response protocol.  The master sends a question, and the slave
>>> cannot send the response before the question arrives, so it is
>>> necessarily half-duplex.
>>>
>>
>>
>> If you asynchrously send over Ethernet, then gather responses with a
>> select() or epoll() loop which then feeds a
>> state machine per MODBUS address, the line
>> itself need never be waited on.
>
> I see what you mean now.  If you are accessing multiple slaves over the
> same Ethernet network you can do this to get better use of the
> bandwidth.  So your Ethernet connection is full duplex, even though each
> individual Modbus connection is half duplex.
>

Yeah, it's messier to explain than you'd think.

>>
>> With RTU over 2-wire 485/422/whatever it's inherently
>> half duplex, and you lose the channel whilst waiting
>> on responses.
>
> The bus turnaround itself is not an major part of the delay - the delays
> are usually while waiting for the slave (server) to put together a
> response.  With RS-485, you can't do anything else during that delay,
> but with Ethernet you can communicate with other slaves while waiting.
> (The same applies to CAN communication.)
>

Right. Plus CAN can be asynchronous* and periodic ( which is weird to 
say but you know what I mean ).

*at least semi-asynchronous - there's more than one way....

I have heard of similar for various MODBUSes but I don't believe it'd 
work for RTU because collisions.

At one place we had a concentrator for 20mA current loop ( not 4-20
analog and not 485/422 - real dinosaur stuff ) which totally solved
this problem. It was still half-dux but there were no collisions
because only one pair at time was hot and each end node has its own
pair. We had a four-byte "poll" message with < 1msec latency and
wait-acknowledge states for queries.

Rock solid system. I put instrumentation in to count errors; zero for
30 days.

>>
>>> But being Ethernet, the connection itself is full duplex (normally).
>>> That means you have have multiple master-slave connections and transfers
>>> going on at the same time.  And since you don't have to have a single
>>> bus master at a time, it is quite possible to have multiple Modbus
>>> masters on the same network at the same time.
>>>
>>> Using UDP reduces the packet overhead a little in comparison to UDP (you
>>> don't need ACK's and connection handshaking), but typically it makes
>>> very little real-world difference.  And TCP/IP is /far/ easier if you
>>> are doing something beyond a simple closed network, such as routing
>>> traffic around, passing it through firewalls, VPNs, wireless bridges,
>>> etc.
>>>
>>
>> This is true until somebody pulls a wire out of a port :)
>
> /Every/ network system will fail when someone pulls out wires!
>

Get a stopwatch out and see how long it takes to actually get an error 
code back from the TCP stack when you leave it unplugged long enough. :)

>>
>>>
>>> And turnaround times are /not/ an issue for carefully implemented MODBUS
>>> RTU.  Unless you have very special bus hardware, the RS485 bus can be
>>> turned around in a bittime or two.  The issue here is how fast the
>>> master can guarantee to switch off its bus drivers - that gives the
>>> minimum latency before the slave can start its reply.
>>
>> So I have seen wait times, including bit times, of 30+ *milliseconds*
>> with some MODBUS implementations ( say @ 38400 BPS for a three-register
>> read or write ) . 10-15 is more typical.
>
> That is delays in the software in the server, not bus turnaround.

Of course. It's delay in the slave nodes ( I don't know how to
use the word "server" w.r.t MODBUS because the topology is inverted ).

> The
> same applies in Modbus over Ethernet, if the server software is equally
> slow - the difference (as noted above) is that you can communicate with
> other servers while waiting.
>
> When I have made Modbus 485 servers, the delays have generally been a
> small fraction of a millisecond - it's just a matter of writing software
> that can respond quickly.
>

Ditto. These were purchased items, not done by us. I wrote a simulator
for these devices and had to add the delay to test things accurately.

>>
>> You're constrained to 31 nodes per wire pair for a reason.
>
> You are indeed constrained to 31 nodes per bus for a reason - but that
> reason is electrical bus load and capacitance, not timing, turnaround
> delays or latencies.  It is part of the RS-485 bus standard which gives
> limits on combinations of bus lengths, speeds, cable loads and the
> number of nodes assuming a "standard" load capacitance.  You can also
> get half-load drivers and have twice as many on a single bus while
> remaining in spec, or even quarter load drivers and have four times as
> many.  Or you can use out-of-spec combinations (such as slower and
> shorter buses) with more nodes.
>
>>
>>> And of course
>>> slave reaction time and latency can be an issue.
>>
>> Right!
>
> That is the key point if you are seeing 30 ms delays.
>

These met all requirements and the latency was not at issue 
operationally. I have no idea how they managed to make
them that slow.

>>
>>> So while it is common
>>> to have long delays before slave replies, in order to handle slow
>>> masters, it is certainly not necessary.
>>>
>>>
>>>
>>
>

-- 
Les Cargill

Am 02.12.2015 um 00:33 schrieb Dimiter_Popoff:
> On 02.12.2015 г. 00:51, Hans-Bernhard Bröker wrote:
>> Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff:

>>> Was not so straight forward as SPI is meant to be unidirectional,

>> Huh?  How do you arrive at classifying a full duplex link like SPI as
>> "unidirectional"?

> I am not sure how you define full duplex but it _is_ unidirectional
> in that the master has no way of knowing - other that the data contents
> it receives from the slave - whether the slave had something to say or
> not.

And I absolutely don't see any sense in which the term "direction" or 
"directional" could have a relation to what you're saying there.  A 
direction is something like "node A to node B", or "node B to node A". 
A single SPI link (unless artificially crippled) between A and B already 
supports both of those directions, fully simultaneously, so I really 
don't see how you justify calling that "uni-directional."

Just because the data sent by one device isn't particularly fresh, or 
has even been flagged "do not use", that doesn't change fact that data 
is travelling from that device to another.

> Likewise, the slave has no way of knowing other than the contents
> of the data byte (word etc., whatever) whether the master did mean to
> send data or was just polling the slave for some output.

SPI as such doesn't care one way or the other, so anything you deduce 
from this argument cannot be a property of SPI.

You appear to be mixing up SPI with how your particular use case of it 
worked.

On 02.12.2015 г. 22:28, Hans-Bernhard Bröker wrote:
> Am 02.12.2015 um 00:33 schrieb Dimiter_Popoff:
>> On 02.12.2015 г. 00:51, Hans-Bernhard Bröker wrote:
>>> Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff:
>
>>>> Was not so straight forward as SPI is meant to be unidirectional,
>
>>> Huh?  How do you arrive at classifying a full duplex link like SPI as
>>> "unidirectional"?
>
>> I am not sure how you define full duplex but it _is_ unidirectional
>> in that the master has no way of knowing - other that the data contents
>> it receives from the slave - whether the slave had something to say or
>> not.
>
> And I absolutely don't see any sense in which the term "direction" or
> "directional" could have a relation to what you're saying there.  A
> direction is something like "node A to node B", or "node B to node A". A
> single SPI link (unless artificially crippled) between A and B already
> supports both of those directions, fully simultaneously, so I really
> don't see how you justify calling that "uni-directional."

You should read more carefully if you want to have success at being
the always know better.

I said SPI was _meant_ to be unidirectional in its use, not that
it was unidirectionl as you claim I have said. IOW, it is _meant_ to
be used either as input or as output, not both at the same time
(e.g. DAC/ADC etc.).
If you do not see the implications of what I described and can call
not knowing if data are present or not  "particularly fresh" I am
afraid I cannot help you much any further.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On 03/12/15 02:36, Dimiter_Popoff wrote:
> On 02.12.2015 г. 22:28, Hans-Bernhard Bröker wrote:
>> Am 02.12.2015 um 00:33 schrieb Dimiter_Popoff:
>>> On 02.12.2015 г. 00:51, Hans-Bernhard Bröker wrote:
>>>> Am 01.12.2015 um 07:14 schrieb Dimiter_Popoff:
>>
>>>>> Was not so straight forward as SPI is meant to be unidirectional,
>>
>>>> Huh?  How do you arrive at classifying a full duplex link like SPI as
>>>> "unidirectional"?
>>
>>> I am not sure how you define full duplex but it _is_ unidirectional
>>> in that the master has no way of knowing - other that the data contents
>>> it receives from the slave - whether the slave had something to say or
>>> not.
>>
>> And I absolutely don't see any sense in which the term "direction" or
>> "directional" could have a relation to what you're saying there.  A
>> direction is something like "node A to node B", or "node B to node A". A
>> single SPI link (unless artificially crippled) between A and B already
>> supports both of those directions, fully simultaneously, so I really
>> don't see how you justify calling that "uni-directional."
> 
> You should read more carefully if you want to have success at being
> the always know better.
> 
> I said SPI was _meant_ to be unidirectional in its use, not that
> it was unidirectionl as you claim I have said. IOW, it is _meant_ to
> be used either as input or as output, not both at the same time
> (e.g. DAC/ADC etc.).

I don't follow you here.  It is common practice to use an SPI bus for
both DACs and ADCs, or other mixes of input and output.  It is also
common practice for SPI communication to an ADC to transfer a new
command to the ADC (such as "start reading from mux channel 3") while
simultaneously reading out the previous conversion value.  I have often
used changes of serial-in, parallel-out and parallel-in, serial-out
logic chips to add lots of simple digital input and output signals to a
board - the output values are sent out simultaneously with reading the
input values.

That is all full duplex, bi-directional communication, even though it is
clearly under the control of a single master at all times.

In SPI, the /control/ - the clock and chip select lines - is
unidirectional.  But the data is bidirectional.

> If you do not see the implications of what I described and can call
> not knowing if data are present or not  "particularly fresh" I am
> afraid I cannot help you much any further.
> 
> Dimiter
> 
> ------------------------------------------------------
> Dimiter Popoff, TGI             http://www.tgi-sci.com
> ------------------------------------------------------
> http://www.flickr.com/photos/didi_tgi/
> 

On Tuesday, December 1, 2015 at 11:32:14 AM UTC+2, David Brown wrote:
 
> With USB3, USB to Ethernet adapters are full speed - the latency is not
> worse than you would normally live with on the average PC.  But with
> USB2 adaptors (the fastest practical for embedded systems), there is a
> bit of extra delay and you are a fair way off GBit speeds.

I've just bought a USB2 to Ethernet adapter - it is WAYYY better than the WiFi link, but agreed -definitely not Gbit