CANBUS Tx/Rx with data length > 8 bytes

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff
Loading thread data ...

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.

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

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.

Right!

--
Les Cargill
Reply to
Les Cargill

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.

Reply to
upsidedown

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.

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.)

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

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 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.

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

Reply to
David Brown

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

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

I have managed to avoid PLCs so far.

--
Les Cargill
Reply to
Les Cargill

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

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.

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. :)

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 ).

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.

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

--
Les Cargill
Reply to
Les Cargill

Am 02.12.2015 um 00:33 schrieb Dimiter_Popoff:

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.

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.

Reply to
Hans-Bernhard Bröker

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

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.

Reply to
David Brown

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

Reply to
Rocky

Am 03.12.2015 um 02:36 schrieb Dimiter_Popoff:

Well, if that's the kind of argument you want to have: you should heed your own advice, starting by reading what _you_ wrote, before making blatantly false claims like the following:

Evidence to the contrary is in the quoted material above, but just in case, look at this:

And that's just as untrue as it was the first two times round.

In any sanely designed physical data link actually _meant_ to be used for data flowing in only one direction at a time, there would be only _one_ data line; the second one would be a total waste. The fact that SPI has both a MOSI and a MISO line is thus pretty compelling evidence against your claims about how it was meant to be used.

I'll agree to that, although I'm quite sure my reasons for arriving at that conclusion are the opposite of yours.

Reply to
Hans-Bernhard Bröker

David, I _know_ that. Moreover I have been doing it over the decades, last time I recall (reading an ADC with an input mux as you describe) was about 10 years ago on that thing:

formatting link

It is quite obvious what I say in my original message, I'll leave the nitpicking whether "unidirectional" is the best chosen word for that to the always know betters on the list, some of whom (not you) have yet to post a message other than "know better" and yet to demonstrate to have ever done something real and working.

While I am sure practically everyone in this group has used SPI in the manner of a plain serial link to shift registers, not many - if anyone except me - has used it as a link between two MCU-s in a way one would use say UARTs, which made me think the story was worth telling; not that I am surprised that the thicker know-betters would locate a word in it to pick on, neither do I care much about it.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

I think the concept you are thinking of is SPI is a 'Single Master' method. Buses like CAN are (at least potentially) 'Multi Master' systems.

(And then non-bussed links like a simple serial port are masterless)

Reply to
Richard Damon

I think it is fairly clear that "unidirectional" was a /bad/ choice of words here - and the result that your original message was not obvious. I have no doubts at all that you understand how SPI works, and how it can be used - it is merely a miscommunication. Even though you call that "nitpicking", remember that posts in a newsgroup are for everyone, and they are archived and searchable for future users. What is a mere minor error amongst experienced developers can confuse other less experienced developers - so it is worth correcting such mistakes.

What is unfortunate is that instead of a "I don't think you wrote what you meant to write" correction, it was more "You are completely wrong" - and tempers have flared, insults have flown (and been treated more seriously than they were meant, I believe). With a bit of luck, it can all end now.

I have also used SPI to communicate between two micros. It wasn't a great choice in my case - it couldn't be much faster than a UART because the slave had no buffering or DMA, so had to use interrupts on the incoming data. But on devices with DMA and good slave SPI support, it can work well.

Reply to
David Brown

How did you handle what I described in my initial message? The "unidirectional" aspect of it I mean (don't know what else to call it, the fact that the master can't know whether the slave had data to send and that the slave has no way of knowing whether the master is clocking in valid data or just clocking it to poll it for output)?

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

I think at the time I just skipped over that bit - your use of "unidirectional" didn't make sense to me, but the rest was fine. I thought perhaps you meant that the individual SPI signals are unidirectional (unlike RS485), which is why it is a lot easier to do galvanic isolation with SPI than RS485.

But what you meant here is that there is one master on the bus which controls everything, rather than multi-master. When you write "unidirectional" in a more general context (and you wrote "SPI is meant to be unidirectional"), I would say the normal interpretation is that you are saying the data flow is "unidirectional" - which is clearly not the case.

Reply to
David Brown

OK, the word choice is not of much importance here as the posts carry enough explanation what they mean (given the posts get read, that is :-) ).

I am curious how you handled that issue at the time you connected MCU-s via SPI?

In my case it is a single master with multiple slaves and individual select lines to each of them; the master (a 68340, this was 1992-3, remember) would talk to one slave (they all were 68HC11...) at a time using the 7 bit protocol I described - and I think it would ensure something like a 1 mS minimum time between bytes so that each HC11 would process the byte (the HC11 code was such that it guaranteed it would cope for that time). Slow but faster than was needed. How did you address all this?

Dimiter

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

I am afraid I can't remember - it was a long time ago. I can't even remember what project it was, or what microcontrollers. But I think the communication was mostly master to slave - the slaves just passed back a status byte or two as the master sent out its commands.

Reply to
David Brown

On 4.12.15 15:31, Dimiter_Popoff wrote: (-- clip clip --)

Years ago, I made a network of 27 AVR slaves connected to one AVR master with SPI. The sources may be somewhere on the archive CD's still.

--

-Tauno Voipio
Reply to
Tauno Voipio

If the available power is an issue, why not switch to some kind of Power Line Communication and you do not need to worry about available power :-)

Of course, the available bandwidth and distance (especially in multiphase systems) will be limited.

So you really have to chose between power and bandwidth.

Reply to
upsidedown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.