LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

timing on RS-485 bus

Solved!
Go to solution

I have been reading all the serial communications resources on here but could still use some context / experienced advice about my application. Here's some background:

 

1) We are communicating with the instrument through a RS-485 to USB converter. I see the instrument in NI MAX and verified the correct COM port and appropriate settings (baud rate, data bits, parity, stop bits) based on the instrument documentation.

 

2) I am using the Simple Serial.vi example to write a command to the instrument. The instrument documentation indicates the instrument expects a carriage return terminator character in the command, so I switch the command to 'Codes Display' on the front panel and add \r after the command.

 

3) I run the Simple Serial.vi and get no response, 0 bytes read. I tried a wide range of 'delay before read' times and always no response. Interestingly I can set my USB converter to echo and I can see the correct write command in the response indicator on the front panel.

 

4) This is the interesting part and my main question. A co-worker of mine developed an application (I think he wrote it in C#) that successfully writes to AND reads from the instrument, and during his development he noticed the instrument engages the bus very quickly after the PC releases the bus. It looks like it only takes less than 1 ms before the instrument responds to the command (see oscilloscope picture). Is this response considered fast? I'm not sure how quickly the VISA VIs are executing. My thought is the VISA Read in Simple Serial.vi is completely missing the instrument transmission.

 

Your thoughts / help is greatly appreciated!!

 

Jeff

0 Kudos
Message 1 of 25
(4,339 Views)

The following info makes a series of cascading assumptions on my part...

 

First thing of note - you don't say so specifically, but your question/problem description implies that your RS-485 serial instrument is connected via two-wire mode, meaning that the transmission path is shared by both the PC and the instrument.  If that is so, you must provide some way for the PC to turn off the transmit driver when it is not actively sending characters.

 

If the serial interface is manufactured by NI, it uses the NI-Serial driver.  If so, directly from LabVIEW, there is a serial property node in VISA to specify the "wire mode" (Serial Settings->Wire mode).  This is NOT done for you by the Simple Serial example VI (there seems to be another example VI which demonstrates RS-485 wire mode control, though I haven't played with it).

 

The VISA node ONLY works if the underlying hardware is NI-Serial - if it's third-party, it'll throw an "unsupported" kind of error.  No worries, you can generally set third-party serial devices in Windows Device Manager through their properties panes, usually in an 'advanced' settings tab/button.

 

In either case (NI -supported or third-party), you'll want to set the interface for a mode described variously as "two wire TxAuto" or "TxReady".  This implies that the PC's transmitter is automatically enabled and disabled in concert with the UART shifting characters out on the line.  It usually also disables the receiver while transmitting, so you don't get unnecessary echoes of your outbound characters.  The instant the last bit shifts out, the transmitter stops driving the line and the receiver is enabled.

 

And you may already know this, but most RS-485 interfaces (certainly true of NI's) do not internally bridge the receiver and transmitter pairs just because you set them for two-wire mode - you have to bridge the appropriate signals in your wiring (Tx+ tied to Rx+, Tx- tied to Rx-, then that + and - pair goes to the two-wire instrument).

 

Hope this helps.

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 2 of 25
(4,312 Views)

Hi Dave

 

Yes that's right I am using a two-wire RS-485 connection. Sorry I forgot to include that.

 

I tried to set the wire mode to 'Wire2-Auto' with a VISA Property Node, but did get the error that the property is not supported by the resource. I am using a third party serial interface so this result was to be expected.

 

Now I am taking a look at the advanced settings for the port, and I'm not quite sure what needs to be changed. I attached a picture of the settings I have available. I played around with a few of the settings with no success.

 

As for the wiring I am pretty certain I have it correct (I am using an EasySync ES-U-3001-M serial interface which has switches to configure it for the appropriate mode. I am using 2-wire half duplex without echo mode.) Additionally my co-worker's application is running successfully on my machine, so I think the problem is somewhere in my Labview application.

 

Any thoughts? Thank you so much

 

Jeff

 

 

0 Kudos
Message 3 of 25
(4,265 Views)

Jeff,

 

I took a look at the EasySync user manual - and it seems like all you need to do is set the DIP switches.  (Cycle power/USB plug/unplug to make sure it gets set?)

 

That's certainly an FTDI-based USB comm port, based on the advanced properties page (I know them well).  So as you say, it's no surprise that the VISA wiremode property write throws an error.  

 

And obviously if your C# program works - on the same PC with the same hardware - cabling pretty much must be correct.

 

I've never been a big fan of the serial examples - too much of your ultimate success with serial depends on getting every little detail right.  Only other thing I can think of is this - are you sending two termination sequences inadvertantly?  This can happen if you have the ASRL end out and termchar settings set to use a termchar, but then explicitly put a termination character in your output data.  Any chance you're doing both?  That might cause a situation where the instrument turns the line around on you while you still have a character (the redundant termchar) outbound.

 

Running low on fresh ideas here.

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 4 of 25
(4,251 Views)

Hi Dave,

 

Thanks for taking the time to look at the EasySync manuals. I do have some solid evidence the DIP switches are working, since when I change the mode to 2-wire echo I see the reflection of the write command in the read indicator in my Labview application...

 

But I just can't seem to get anything from the instrument! I like your theory that termination characters may be getting mixed up. I noticed the VISA Configure Serial Port VI defaults to both TRUE for the termination character and then uses a linefeed character. But the documentation I have specifies a carriage return termination character on both the write command and read response packets.

 

However I ran the attached Labview application (shown in simple serial v2.png) and still get no response. I set the termination character to 13 which indicates the carriage return. I then got a little paranoid the VISA Configure Serial Port VI defaults were still attaching the linefeed character, so I made one last effort with an application (shown in simple serial v3.png) which simply uses VISA Open instead. I noticed this allows me to load port settings I configured with the Device Manager as you suggested. Full of hope I ran this application and still got no response.

 

I am out of ideas. If you see anything odd in the screenshots of the attached programs, let me know. Otherwise I really appreciate your help.

 

Jeff

 

Ps. Thought you deserve some context for helping. I am trying to get my co-worker’s C# application working in Labview as I previously wrote a control program in Labview which cycles anchors (as in anchors that hold stuff to the seafloor) up and down based on load or position limits. We are hoping to use this same cycling functionality with a new serial instrument (a cone penetrometer) which determines the strength of the seafloor materials. So here I am a civil engineer caught up in the fun world of instrumentation and testing!

0 Kudos
Message 5 of 25
(4,227 Views)

Here are the attachments.

Download All
0 Kudos
Message 6 of 25
(4,224 Views)

Whoa, Jeff!

 

Please tell me you type a number into the box you label "Bytes Read" before running this code. Because that is a control - meaning an input to the VISA Read, not an output - and if you leave that control at zero, you won't get anything back (in fact, you'll get that exact "warning" - number of bytes requested equals bytes transferred - because zero is, well, zero).

 

For devices which reliably send a termination character, the preferred solution is to set up VISA with that termchar for "end in" (generally as well as "end out", if the protocol is consistent), and then feed the VISA Read byte count with any outsized number greater than the largest message ever expected.  The read will return success when it hits the termchar.  There *IS* an output (return count) that tells you the actual response length (or you can just test the stringlength).

 

Am hoping this is just a case of putting a big number in that box, making sure you're set for termchar on *input*, and boom...  If this works, you can dispense with the fixed delay time too - just set the VISA timeout to the maximum expected instrument response time, with a little safety margin.  The code will complete as soon as the message arrives, that way.

 

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 7 of 25
(4,211 Views)

Hi Dave,

 

Ah I wish that was the problem! I was careless in taking the screen capture of the program. For all of my runs I used the 'Bytes at Port' property as the control for VISA Read. At one point I removed the property node and entered a few different byte counts into the control for VISA Read. I got the standard VISA Read timeout error after doing this. I must have done the screen capture after running it with zero by accident.

 

That is nice to know I can set the termchar for 'end in' and 'end out'. I added that property, put a big number in the VISA Read bytes control, and then set the VISA Read timeout to 5 s (I know this is plenty of time as the C# application runs at about 5 Hz), and alas still no response. If I ever get this instrument responding I sure will know the best way to do things with NI VISA!

 

Thanks,

Jeff

 

Ps. I attached the program I just ran with the above suggestions. Just in case you see anything odd...

 

 

0 Kudos
Message 8 of 25
(4,196 Views)
Jeff,
Sorry, but I don't see anything overtly suspicious with your last screen grab. Are you sure the device is eight bit AND even parity? That's not a combination I've seen before. Any chance you can say the instrument name? Or you can PM it to me if the development is confidential.

Dave
David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
0 Kudos
Message 9 of 25
(4,180 Views)

Hi Dave,

 

Yes the documentation I have is very clear that the device uses 8 data bits and even parity. Although I see that 8 data bits and no parity is much more common. Let me check to make sure I can send some information about the instrument. It should be fine and I'll plan to message you some details at the end of the day today.

 

Thanks again!

Jeff

0 Kudos
Message 10 of 25
(4,132 Views)