timing on RS-485 bus

[PatrickLye]

It looks like wireshark can monitor the usb traffic. I haven't used it yet, but plan to try it on a project I'm starting soon.

https://wiki.wireshark.org/CaptureSetup/USB

[RavensFan]

---

@DavidBoyd wrote:

I'm going to have to respectfully disagree with you here.  You absolutely SHOULD use the END IN functionality of VISA to your advantage (for instruments/devices which support a single-character terminated protocol) because it alleviates a lot of the nonsense of polling for characters at the port, reading partial messages which then must be concatenated, figuring out your own timeouts in loops, all of which are major pain points especially for neophyte developers.  And I would strongly suggest that application-level programming SHOULD NOT concern itself with adding its own outgoing termination.  There are legacy reasons for this as well - where an instrument can be accessed through more than one interface (serial vs. IEEE-488), it allows you to abstract some of the interface particulars out of your driver level code.

I absolutely prefer to let VISA do the "back end crap", which it does so well.

Dave  (waiting for a REALLY interesting side conversation to start, now.  And RavensFan, I have the greatest respect for you as an active participant here - just so that's clear).

---

Maybe I wasn't as clear in my message as I could have been.  I agree with you about polling or characters is a lot of nonsense.  (maybe for a very small percentage of applications does it make sense, and they usually don't have very well defined protocols anyway).  Any message I've ever written in the forums talks about "bytes at port" being the wrong method the vast majority of the time.

That said, there is no need for the END IN property nodes on reading because the handling of the termination character on incoming messages as already been handled by the Serial Configure VI.

As for the END OUT property, I disagree with you about having the VISA driver handle the termination character.  The application should handle.  It is the programmer of the application that knows and understands the protocol of the messages that need to be sent.  Whether it ends in one termination character or another, or needs checksums, or command bytes or anything else.  It is an integral part of the message being sent out, not something that should just be tacked onto the back end of the message.

I think of it this way.  Suppose I'm the boss and I have an employee I'm giving instructions to.  I would prefer to be the one to say,  "Hey do, A, B, and C, okay, I'm done, go off and do that" thus terminating my commands.  That is what it is like to include the termination character with the message I'm sending.  The alternative is at the beginning of the day I say "when I give you a message, you decide when I'm done talking and go off and follow my commands"    Then all through the day, I give commands and then have the employee hang around for a few more seconds deciding if I'm going to say anything else.  Maybe I'm even speaking slowly for some reason at that moment and he leaves before I even finish I message.  That is what it is like to have the automatic termination being added to outgoing messages.  It doesn't seem to be as efficient, and I could see how it can cause an unneeded delay in finishing off a VISA Write.  Let me, the creator of the message decide when it is done and not some intermediate driver layer that knows nothing about the actual messages I'm trying to send.

[Dan_Mondrik]

From where I stand, you're both right. (And I'm not being wishy washy about this; I'm not afraid to take sides.)

The extra serial "end" termination functionality in VISA is especially useful for instruments that have both GPIB and Serial ports and often have "special" behavior when using Serial. You should let VISA handle that abstraction for you, as long as it works. Setting up the "end out" behavior for write operations is only compensating for the fact that Serial can't provide EOI like GPIB does because 9 wires just isn't enough. In many cases for these multi-bus instruments, if the VISA termination handling works (which I believe it often does), you should absolutely use it and not worry about the fact that the characters across the bus do indeed differ slgihtly.

On the other hand, if you're dealing with something that you know is Serial and it's not important to try to make it abstract for other interface types, then by all means skip the special behavior and make things explicit. Especially when you're having trouble communicating with the device (which is what this entire post seems to be about), don't let an abstraction layer give you grief. It's not just about functionality, though. The fewer special behaviors you rely on, the more readable and maintainable your code is. And don't forget that another (obvious) reason to avoid using the special VISA termination character behavior is if you're dealing with messages that contain binary data.

Not having read the manual for this instrument, I'd guess that it says in 1 place that for Serial you need to terminate commands with '\r' but does not include the '\r' in every documented command. This thought process would probably lead me towards writing the code such that the '\r' happens in 1 place rather than in every calling VI. Whether that's in a sub-VI that wraps the VISA Write or whether it uses the VISA "end" functionality, that's up to you. Either way, I would definitely recommend doing it all in a single call to VISA Write rather than in 2 calls, because the amount of time in between those 2 can lead to intermittent timing issues such as those that RavensFan talks about.

There's also a compromise in the middle. You may find that it's more explicit to incorporate the '\r' in your commands to VISA Write so that the sending is explicit, but let VISA handle termination characters for you when reading, because in my opinion that's where VISA adds the most value for Serial.

In either case, it doesn't quite sound like this specific setting is what's actually causing your communications problems. I wish you luck in getting that working.

[DavidBoyd · Accepted solution]

Thanks, Dan, for your well-thought-out comments.  Just so you know (and anyone else following this thread), I've been in direct touch with the OP and he sent me some docs concerning the instrument in question.  I spotted some inconsistencies between what his C# programmer documented vs. what the instrument manufacturer lists, in regards to databits and parity settings.  Turns out it was a simple case of character-level format, and his LV code is transacting messages now.  I expect he'll show back up here soon (well, he *said* he would) with a wrapup report.

Again, thanks for offering up your thoughts - over the years I've definitely pegged you as "Doctor VISA".

Dave

P.S.  if I had one wish for a major feature update to VISA, it would be some kind of regex definition of what constitutes a termination sequence or message block.  So many serial protocols I've had to communicate with (both commercial instrumentation and our own developed products I test), where there is no simple termchar - but where the mesage format follows other rules - and wished for a way to offload some of the work to VISA.

[JThorus]

Hi all

Thank you all for your responses. This is my first time working with a serial instrument so the discussion on communication protocol has been really helpful. As Dave mentioned unfortunately I was given some incorrect documentation about my third party instrument. Due to my inexperience I sort of considered a number of different sources of the problem at first. Very frustrating but thankfully I had a C# application that was working, and was able to dive into that code and find the correct address, data bits, parity, etc.

When I get some extra time on my hands I would like to post on here what I can get out of the WireShark traffic monitoring while running the C# application. That was an interesting idea suggested at one point to reverse engineer my way out of this problem.

Finally...as long as all the experts are here, I would like to make a shameless plug to check out another thread ('running serial task and AI task continuously') I just started. I am moving toward communicating with this instrument continuously while running an analog input operation. I have both the serial task and AI task in the same loop and seemingly regardless of the loop speed I get a timeout error - the serial read cannot complete in time. Anyway more on this in the other thread.

Thank you all for your time! Can't emphasize enough how helpful this has been.

Jeff