Reply by Jan Panteltje September 24, 20132013-09-24
On a sunny day (Mon, 23 Sep 2013 23:00:21 +0300) it happened
upsidedown@downunder.com wrote in
<rn6149dvvova3p7qm5b99gt0a0qju2g4vf@4ax.com>:

>On 23 Sep 2013 07:21:24 GMT, Jasen Betts <jasen@xnet.co.nz> wrote: > >> >>Getting 3.5+ character-times of slience out of a 16540 UART seems tricky, >> >>Perhaps wait for the shift-register0-empty flag to be set and then turn off >>the transmitter then send 4 characters of dummy data, and wait for >>the empty flag again. (that gets you 4+ character times)... >> >>I don't expect that will be easy to do with a typical OS-provided serial >>driver, and a USB UART would be even worse, > >The 14550 UART is a brain dead construction even for RS-485, not to >mention Modbus RTU. > >In that idiot design, you can get an interrupt, when the last byte is >transferred _into_ the shift register. For any practical RS-485 >purposes, the only interesting time is when the last transmitted >message last stop bit has been actually sent. > >For the idiotic 14550 chip the only way to detect this is by polling >(busy looping) a HW register (no interrupt available), until that bit >is actually sent. > >While this might be acceptable for single thread executive like >PC/MS-DOS, this is completely unacceptable in any multitasking >environment.
I dunno exactly, but you could set a timer, and test the bit in that timer interrupt, that way the code can continue. Or test the bit the next time the scheduler was around. Slower, perhaps, but what is slow.. Preemptive?
Reply by Przemek Klosowski September 24, 20132013-09-24
On Thu, 19 Sep 2013 20:23:59 -0400, Spehro Pefhany wrote:

> On Thu, 19 Sep 2013 13:30:12 -0700 (PDT), the renowned Klaus Kragelund > <klauskvik@hotmail.com> wrote:
>>Is there any way to "tell" the PC to use a specific standard so its >>possible to have the scope trigger on a TCP/IP packet?
> Have you tried Wireshark (free)?
One thing you have to remember about wireshark is that it has to be in the same domain as your endpoints: either on one of them, listening to the same interface used for communication, or on a network HUB. If you connect it to the network switch, it will only see the broadcast traffic. Sorry for being Cap't Obvious here but it's easy to forget this unless you work with it all the time---ask me how I know.
Reply by Tauno Voipio September 23, 20132013-09-23
On 23.9.13 11:00 , upsidedown@downunder.com wrote:
> On 23 Sep 2013 07:21:24 GMT, Jasen Betts <jasen@xnet.co.nz> wrote: > >> >> Getting 3.5+ character-times of slience out of a 16540 UART seems tricky, >> >> Perhaps wait for the shift-register0-empty flag to be set and then turn off >> the transmitter then send 4 characters of dummy data, and wait for >> the empty flag again. (that gets you 4+ character times)... >> >> I don't expect that will be easy to do with a typical OS-provided serial >> driver, and a USB UART would be even worse, > > The 14550 UART is a brain dead construction even for RS-485, not to > mention Modbus RTU. > > In that idiot design, you can get an interrupt, when the last byte is > transferred _into_ the shift register. For any practical RS-485 > purposes, the only interesting time is when the last transmitted > message last stop bit has been actually sent. > > For the idiotic 14550 chip the only way to detect this is by polling > (busy looping) a HW register (no interrupt available), until that bit > is actually sent. > > While this might be acceptable for single thread executive like > PC/MS-DOS, this is completely unacceptable in any multitasking > environment.
Remember that the 8250 (base model for PC async serial interface) was made for RS-232 modem connections. It is not interesting when sending is done, only when more can be pushed to the pipeline. The same applies even more to the newer versions with FIFOs. -- -TV
Reply by September 23, 20132013-09-23
On 23 Sep 2013 07:21:24 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:

> >Getting 3.5+ character-times of slience out of a 16540 UART seems tricky, > >Perhaps wait for the shift-register0-empty flag to be set and then turn off >the transmitter then send 4 characters of dummy data, and wait for >the empty flag again. (that gets you 4+ character times)... > >I don't expect that will be easy to do with a typical OS-provided serial >driver, and a USB UART would be even worse,
The 14550 UART is a brain dead construction even for RS-485, not to mention Modbus RTU. In that idiot design, you can get an interrupt, when the last byte is transferred _into_ the shift register. For any practical RS-485 purposes, the only interesting time is when the last transmitted message last stop bit has been actually sent. For the idiotic 14550 chip the only way to detect this is by polling (busy looping) a HW register (no interrupt available), until that bit is actually sent. While this might be acceptable for single thread executive like PC/MS-DOS, this is completely unacceptable in any multitasking environment.
Reply by Tauno Voipio September 23, 20132013-09-23
On 23.9.13 10:21 , Jasen Betts wrote:

> Getting 3.5+ character-times of slience out of a 16540 UART seems tricky, > > Perhaps wait for the shift-register0-empty flag to be set and then turn off > the transmitter then send 4 characters of dummy data, and wait for > the empty flag again. (that gets you 4+ character times)... > > I don't expect that will be easy to do with a typical OS-provided serial > driver, and a USB UART would be even worse,
To add insult to injury, the requirement for timed framing makes it impossible to use hardware FIFOs, as they lose the timing. -- -TV
Reply by Klaus Kragelund September 23, 20132013-09-23
On Monday, September 23, 2013 10:07:10 AM UTC+2, Jan Panteltje wrote:
> On a sunny day (Mon, 23 Sep 2013 00:39:52 -0700 (PDT)) it happened Klaus > > Kragelund <klauskvik@hotmail.com> wrote in > > <27450a3c-90d9-4358-b0d9-142ba9170baa@googlegroups.com>: > > > > >> TCP side, including gateway, ethernet switches and NICs. > > > > > >For the tests we are asking for the return of 2 registers (4 bytes) > > > > > >That is what corresponds to process data, values that needs to be monitored to what seems like realtime > > > > I dunno if anybody mentioned this, but in TCP/IP > > there is the acknowledge packet (or not). > > You cannot reliably see if your data is received UNLESS you got that confirmation back. > > This is what makes TCP/IP so much slower than UDP. > > But then UDP may have packets lost. > > The point is that TCP, via the same network ALSO will lose packets sometimes. > > but then those will be re-transmitted. > >
Point taken, thanks :-) Cheers Klaus
Reply by JW September 23, 20132013-09-23
On Fri, 20 Sep 2013 12:49:03 -0700 Jeff Liebermann <jeffl@cruzio.com>
wrote in Message id: <hg9p399sgfllk3knpln2ipcuj303ire6v3@4ax.com>:

>Install an RS-485 loop back adapter in the RS-485 port.
You cannot loop back a half-duplex RS-485 port.
Reply by Jan Panteltje September 23, 20132013-09-23
On a sunny day (Mon, 23 Sep 2013 00:39:52 -0700 (PDT)) it happened Klaus
Kragelund <klauskvik@hotmail.com> wrote in
<27450a3c-90d9-4358-b0d9-142ba9170baa@googlegroups.com>:

>> TCP side, including gateway, ethernet switches and NICs. > >For the tests we are asking for the return of 2 registers (4 bytes) > >That is what corresponds to process data, values that needs to be monitored to what seems like realtime
I dunno if anybody mentioned this, but in TCP/IP there is the acknowledge packet (or not). You cannot reliably see if your data is received UNLESS you got that confirmation back. This is what makes TCP/IP so much slower than UDP. But then UDP may have packets lost. The point is that TCP, via the same network ALSO will lose packets sometimes. but then those will be re-transmitted. So it seems to be silly to ask for a guaranteed minimum time, unless you have the perfect network (cable), and even then (collisions in ethernet etc). So you can basically NEVER guarantee a minimum delay. But you could make a good guess as to how often the next nuke plant goes China (Syndrome), and the same way for the probability that a data packet will arrive out of your specified window in time. Hey!
Reply by Klaus Kragelund September 23, 20132013-09-23
On Sunday, September 22, 2013 9:53:34 AM UTC+2, upsid...@downunder.com wrote:
> On Sat, 21 Sep 2013 14:51:41 -0700 (PDT), Klaus Kragelund > > <klauskvik@hotmail.com> wrote: > > > > > > > >> > > >> >I would be satisfied with 0.1ms resolution, that would be more > > >> > > >> >than good (the unit without a gateway has 25ms turn-around time > > >> > > >> > > >> > > >> What unit? What and how are you measuring latency? > > >> > > > > > >Our own unit. Measuring the start of the master transmission to the end of the telegram from the slave > > > > That is pretty fast if measured with a maximum size read or write > > transaction, since it takes about 25 ms at 115k2 transferring 125 > > registers in either direction, so there is not much turn-around time > > at the slave. > > > > However, if that 25 ms is measured for a short transfer (1 register), > > which only should take 2-5 ms, as calculated in my previous post, the > > performance is bad. > > > > Contrast to this, I do not understand why you need 0.1 ms resolution > > in your timing analysis, 1 ms should be sufficient. In a Windows > > program, you should get 1 ms resolution time stamps, if you enable the > > multimedia timers at program startup.
I guess 1ms should be ok, it translates to a 5% error in the measurement. Cannot be much higher though Cheers Klaus
Reply by Klaus Kragelund September 23, 20132013-09-23
On Sunday, September 22, 2013 9:42:21 AM UTC+2, upsid...@downunder.com wrote:
> On Sat, 21 Sep 2013 15:05:05 -0700 (PDT), Klaus Kragelund > > <klauskvik@hotmail.com> wrote: > > > > >> What is your serial speed ? > > > > >Maximum 115.2kbaud > > > > >> In any half duplex protocols, such as Modbus RTU, the total throughput > > >> will increase by much less than a factor of 2, when doubling the line > > >> speed, due to various fixed delays, thus there is a diminishing return > > >> when increasing line speed. > > > > >Yes, the 3.5c is a fixed value of 1.75ms above 19.2kbaud, so it really begins to count > > > > A short transaction e.g. for writing a single coil or register > > contains 8 bytes or 88 bits with parity in both request as well in > > response. At 115k2 a frame is 0.76 ms long and if you use the > > recommended 1.75 ms gap, the total transaction takes 5 ms. > > Even with 3.5 character times, the transaction takes more than 2 ms. > > > > These are long times compared to what you would expect to see on the > > TCP side, including gateway, ethernet switches and NICs.
For the tests we are asking for the return of 2 registers (4 bytes) That is what corresponds to process data, values that needs to be monitored to what seems like realtime Cheers Klaus