From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Visa Serial Control

Solved!
Go to solution

I agree with you on this, but why would I format differently then with VISA Interactive Control. With my experience on other instruments tells me what works in VISA Interactive Control is what will work in your vi. Why would these be different then?

 

I will try quickly to see if the string as hexadecimal will work.

0 Kudos
Message 11 of 21
(1,880 Views)

I agree with you on this, but why would I format differently then with VISA Interactive Control. With my experience on other instruments tells me what works in VISA Interactive Control is what will work in your vi. Why would these be different then?

 

I will try quickly to see if the string as hexadecimal will work.

So, I changed the string to hex display of string and received this error now...

-1073807346

0 Kudos
Message 12 of 21
(1,876 Views)

@arwc wrote:

I went back to Visa Interactive to check the settings and have attached them here. When I change the end mode for writes to "none" then the termination character option is no longer an option. I attached the Visa communication from interactive if that helps.

 

When I match exactly these settings in labview vi I still get the following error on my read...

-1073807339 error

Also, when I use the light bulb to track progress it always say "OK" on Visa write.


This message doesn't make any sense.  I never said go back to the VISA interactive and make it none.

 

Here is the situation as you originally described it.

1.  Interactive control works.  You also have the Termination "Send End on Writes" enabled.  That means when you write something in that dialog, eg.  "ABCDEFG", it actually sends ABCDEFG{CR}"  or perhaps a linefeed instead of a carriage return.

2.  You VI doesn't work.  You aren't sending any termination character.  So if you are sending "ABCDEFG", that is all that it is sending.  Nothing else.  Nothing that tells your device you ended the message.

 

Do you see the difference between #1 and #2 in what is happening?  So why would you go and change #1 to no termination to match the non-working VI.  Wouldn't it make sense to change the VI to match what is happening in #1?

 

Get rid of the property node block in your VI.  Use the VISA Serial Configure.

Also, VISA Write will pretty much always say OK unless you have a very serious and unusual problem with your serial port.

 

 

0 Kudos
Message 13 of 21
(1,870 Views)

OK. Now I have added the termination character in the string.

I am unclear what the purpose of the VISA serial function you have in your vi. Can you please explain?

0 Kudos
Message 14 of 21
(1,863 Views)

It sets the parameters in a single subVI rather than having to drop in a property node.  If you open it up, you'll see it has a property node inside of it.

 

I'm surprised you haven't seen that subVI before.  It is the very first item in the Serial palette under Instrument I/O.

 

Are you sure you entered the termination character correctly?  Earlier, I had the impression that all of your backslashes and hex characters were all literal.  In which case your constant is set for normal mode.  That \00 is not sending a single byte of value, 0, but literally sending {backslash} "0" and "0".  If that is the case, then the \r you added is wrong because you are not sending a carriage return but a literal backslash and "r".

 

Also, instead of us guessing at what your are supposed to be sending, attach a link to the manual for your device.

 

If your constant is in \ code mode, then you are sending fewer bytes, and you are sending a carriage return.  But it is very unusual for a device that sends "binary" data (as in bytes that don't from human readable characters) to also use a termination character, because a decimal value of 13 is just as likely to occur in binary data as any other byte value from 0 to 255.

 

If your string constant is in \code mode, then be sure to right click on it and make the display mode visible.

If it is in "normal mode", the \r is wrong.  Change it to \code mode and retype it there as \r.

0 Kudos
Message 15 of 21
(1,857 Views)

Just to visualize what Ravens refer to:

StringConstantConfiguration.png

 

You have to either switch to Hex or '\' Code Display. If you chose the first option, the '\' must stay out as i recommended initially.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 16 of 21
(1,850 Views)

OK. I checked and I was in normal mode not in \ mode for my string.

 

Do you think that sub vi is more effective then the way I have a property node set up now?

0 Kudos
Message 17 of 21
(1,842 Views)
0 Kudos
Message 18 of 21
(1,840 Views)

Have your read Appendix D of that manual?

 

I'm really wondering how you got the VISA interactive control to work.  But reviewing all the messages, I'm not sure you ever stated anywhere what you were actually sending with that dialog box.

 

I can tell you that you are doing everything wrong with your LabVIEW code.

 

First, it looks like it is supposed to be all binary, in which case you DO NOT want to send a termination character.  Your VISA interactive control had that enabled, but perhaps you got lucky and the device just ignored the extra byte on the end.

Your LabVIEW code of sending "\CA\00\01\F0\02\00\FA\12" is definitely wrong because that was in normal display.  According to appendix D, you are supposed to be sending binary data, but you are sending a literal back slash "C"  and "A" rather than a hex byte of value CA.

 

1.  Disable the termination character on the VISA Configure (Yes, I recommend the subVI rather than your property node).

2.  Do not include a carriage return on any command you send.

3.  Set your constant to Hex display and type in the characters you want to send.  (you will not be typing any backslashes, I'm not even sure why you thought there should be backslashes.)

4.  Try that.

5.  Read the manual and especially appendix D.  You might have to change what you send because things like the checksum would change.

0 Kudos
Message 19 of 21
(1,828 Views)
Solution
Accepted by topic author arwc

@arwc wrote:

Here is the manual for my instrument

http://www.idealvac.com/files/manuals/Chiller_Neslab_ThermoFlex-900-2500_Manual.pdf


I'll try to help out. I don't have a NESLAB Chiller so I cannot vouch that these snippets will work. You will have to iron out the details.

 

From what I seen in the manual, the chiller does not use a termination character. You do not need to add one. The length of the message is embedded in the command. This is how I would build up the command syntax that the master would send.

Front Panel (write).PNG

NESLAB Write.png

 

 

 

 

Reading the response from the slave is a little bit trickier since it does not send a termination character (make sure you DISABLE the TermChar when calling the VISA Config VI), but it has a well defined format for the response. First read in the preamble (first four bytes). Then read one byte to calculate the number of bytes to follow. Convert that hex string to an unsigned intereger and use that value to read in all the remaining data. Lastly you have an extra 1 byte to read to get the CRC checksum.

 

NESLAB Read.png

Message 20 of 21
(1,802 Views)