LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VISA Serial write problem

Hello,
 
I'm pretty new to using LabVIEW so please bear with me as I try to explain and work through this. 
 
I'm using VISA Serial and VISA Write to operate a couple of motion controllers for a project I'm working on. What is interesting is that the program commands sometimes work and sometimes don't.  The program I currently have is quite simple in order to understand what's going on, but I find that when I click run about 30% of the time the command actually makes the device move as its supposed to.  The other times no motion will happen, but with an indicator that information IS being sent and received.  Every time that I click run, the lights on the motion controller flash, indicating that it's receiving information, but like I said only about 30-40% of the time do results actually show.  Very occasionally (~10%) of the time the device will start to move and cut-off before the full movement is completed. 
 
What I am guessing is that the information is being delivered to the device, but not necessarily always in the order intended to be sent, like it all happens so fast it can arrive in a jumbled order.  Is this even a possibility?  To try to fix this, I added "serial break" commands in between each write statement, but there was no response after that.  Does anybody have any pointers for me in this area?  I will attach the code here to show what is being sent ... keep in mind that when I tried the serial break addition I placed this inbetween each of the write statements.  Also, I have seen in this forum that I can change the write command to automatically add the carriage return character, but haven't gotten around to changing my program yet, so I just concactenate the string together.  Thanks for the help!
 
~Jack
0 Kudos
Message 1 of 10
(5,948 Views)
Your VISA Writes are strung up in series, so the motion controller is not receiving them in the wrong order. What's more likely is that you need to wait between some, or all of the commands. If you run the VI in highlight mode, does it work all the time? If so, then you need to insert some delay to allow the motion controller to do its thing before going on to the next command. You can try the same commands in HyperTerminal, as that will effectively wait between commands since you've got to type them in.

Also:
  • You should wire the error cluster through to catch errors.
  • I don't know if you're using this in a higher-level program, but you should perform the VISA Configure once, not every time you talk to the device. Also, you should perform a VISA Close at the end of the program to free up the resource.
Message 2 of 10
(5,931 Views)
Ok, like I said I'm pretty new, but running it in highlight mode did allow it to work all of the time and I did wire in the errors to catch any thay may pop-up.
 
Two things, first what do you mean by the "you should perform the VISA Configure once, not every time you talk to the device" line?  What in my program specifies that I am configuring every time?  Does this mean I don't need to connect to the Visa Resource Name on each write statement and that doing it at the beginning is fine as long as they are in series? 
 
Second, since it works in highlight mode (which effectively introduces the delay) how can I introduce this delay automatically in programming?  I don't want to type these commands in manually as this is just a test program to get the correct commands and functionality, moving on I am going to have a much more complicated program that accepts certain angles on a rotary device, and certain distances on a linear to align two instruments correctly, which will be much easier if I can enter angle and location, processing in LabVIEW the numerous commands this would take, and moving them correctly.  I had tried the serial break command, but no responses came from this ... is that a mis-use of serial break and either way do you have any advice on how to introduce the delay without manual typing?
 
Thanks for the help!
 
~Jack
0 Kudos
Message 3 of 10
(5,914 Views)
Ok so in the mean-time I've accidently solved my own problem.  Let me know if my guess may be accurate, or if you anybody has a better explanation.  While trying to figure out how to change the operating mode and include some breaks in the serial alignment, I added the return carriage termination character into the chaing ... where this effectively made the thing work.  Somehow adding the termination character into the loop caused the lag necessary (or sent the messages "better" which I have no idea what better means) for the system to always respond correctly.  Meaning that everytime I run it now (not in highlight mode) it responds and acts accordingly. 
 
Any better explanations why this works?  I'm glad it does and will move forward, but wouldn't mind a better explanation.  Here's the new code for fun (it has a second motion controller wired in for a movement as well).  Thanks!
 
~Jack
0 Kudos
Message 4 of 10
(5,899 Views)
The "Termination Character Enable" applies only to Read operations. This is stated in the online Help and in the Context Help when you hover the cursor over that property. So setting this in your case does nothing. To control how to terminate a write operation you set the "Message Based Settings->Send End Enable" property. This should default to True. Then, you specify how to end the write with the "Serial Settings->End Mode for Writes" (ASRL End Out). The default is "None", which means that nothing gets appended to the string you provide to VISA Write. Since you are now specifying to use "TermChar", and you're setting the termination character to CR, then each string you write gets a carriage return appended to it.

What I meant by doing the configuration once is that if the VI you wrote is going to be called numerous times as a subVI then it makes no sense to configure the serial port each and every time you want to send a command to the motion controller. You configure the port at the beginning of the programs, run your program which sends commands to a port, and then close the port at the end.

Now, as to why it works, well, you said initially that your original code worked sometimes. Isn't it likely that you're just seeing the same thing? You need to check the documentation on the motion controller to see what it says about sending multiple commands and whether or not any time delay is required after some commands. As for placing a delay, there's a "Time Delay" VI in the Timing palette that you can wire in place using the error clusters.
Message 5 of 10
(5,891 Views)
Hey, thanks for the interest. 
 
I must have the nomenclature wrong, but whatever I added and am calling the termination character influences the write statements as I got the instructions from the following forum topic: http://forums.ni.com/ni/board/message?board.id=170&message.id=67889&query.id=114293#M67889
 
In the directions entitled "Adding a Termination Character to VISA Serial Writes" I did exactly what the recommendations were and got my commands to run, but when I take the line out and hook up the series of commands nothing happens, so somehow this added the carriage return value I needed. 
 
Also, regarding my code working after the addition.  Before I would get about 30% results, but after adding that "line" or "node" (whatever it's called) it worked correctly over 100 times in a row (before I was lucky to get 2 in a row), therefore it at the very least slowed down the commands enough for stuff to get done. 
 
The problem really isn't solved though as I need to stack 2 moves in a row and the first move doesn't have enough time to complete before the second command gets there, therefore I need a delay and much to my delight you have suggested a time delay (where I know the maximum length I have to wait for any given scenario), so I'll give that a try and see how it turns out.  Thanks again for your suggestions and help as I stumble through this, it's really helpful for me. 
 
~Jack
0 Kudos
Message 6 of 10
(5,878 Views)
You've got the correct property to automatically terminate the writes. The TermChar Enable must be true and the ASRL End Out has to set to 2. The VISA Configure Serial Port sets TermChar Enable to true and ASRL End In to 2.
0 Kudos
Message 7 of 10
(5,868 Views)
OK... Now I'm confused...

The VISA documentation states that "VI_ATTR_SEND_END_EN specifies whether to assert END during the transfer of the last byte of the buffer." ... "On Serial INSTR sessions, if this attribute is set to VI_FALSE, the write will transmit the exact contents of the user buffer, without modifying it and without appending anything to the data being written. If this attribute is set to VI_TRUE, VISA will perform the behavior described in VI_ATTR_ASRL_END_OUT." This corresponds to "Message Based Settings->Send End Enable" (Send End En), no?

For VI_ATTR_ASRL_END_OUT it says that it "indicates the method used to terminate write operations." ... "If it is set to VI_ASRL_END_TERMCHAR, and VI_ATTR_SEND_END_EN is set to VI_TRUE, the write will send the character in VI_ATTR_TERMCHAR after the data being transmitted. If VI_ATTR_SEND_END_EN is set to VI_FALSE, the write will transmit the exact contents of the user buffer, without modifying it and without appending anything to the data being written." This corresponds to "Serial Settings->End Mode for Writes" (ASRL End Out), right?

For VI_ATTR_TERMCHAR_EN it says that it "is a flag that determines whether the read operation should terminate when a termination character is received. This attribute is valid for both raw I/O (viRead) and formatted I/O (viScanf).". It doesn't say anything about writes. This corresponds to "Message Based Settings->Termination Character Enable" (TermChar En), right?

Why would you need to set VI_ATTR_TERMCHAR_EN if you're just doing writes? Admittedly, I've never done VISA Writes to the serial port in this fashion, as I've had wrapper functions for instruments that were serial based, and I handled the message formatting withing the "Write" VIs, and they just added a carriage return. I just found this easier than messing around with VISA properties.
0 Kudos
Message 8 of 10
(5,859 Views)
On May 18, 10:10 am, hasqual <x...@no.email> wrote:
> Hello,
> &nbsp;
> I'm pretty new to using LabVIEW so please bear with me as I try to explain and work through this.&nbsp;
> &nbsp;
> I'm using VISA Serial and VISA Write to operate a couple of motion controllers for a project I'm working on. What is interesting is that the program commands&nbsp;sometimes work and sometimes don't.&nbsp; The program I currently have is quite simple in order to understand what's going on, but I find that when I click run about 30% of the time the command actually makes the device move as its supposed to.&nbsp; The other times no motion&nbsp;will happen, but with an indicator that information&nbsp;IS being sent and received.&nbsp; Every time that I click run, the lights on the motion controller flash, indicating that it's receiving information, but like I said only about 30-40% of the time do results actually show.&nbsp; Very occasionally (~10%) of the time the device will start to move and cut-off before the full movement is completed.&nbsp;
> &nbsp;
> What I am guessing is that the information is being delivered to the device, but not necessarily always in the order intended to be sent, like it all happens so fast it can arrive in a jumbled order.&nbsp; Is this even a possibility?&nbsp; To try to fix this, I added "serial break" commands in between each write statement, but there was no response after that.&nbsp; Does anybody have any pointers for me in this area?&nbsp; I will attach the code here to show what is being sent ... keep in mind that when I tried the serial break addition I placed this inbetween each of the write statements.&nbsp; Also, I have seen in this forum that I can change the write command to automatically add the carriage return character, but haven't gotten around to changing my program yet, so I just concactenate the string together.&nbsp; Thanks for the help!
> &nbsp;
> ~Jack
>
> serial1.vi:http://forums.ni.com/attachments/ni/170/248121/1/serial1.vi


0 Kudos
Message 9 of 10
(5,847 Views)
Hmm... I guess Dennis is not listening to this thread anymore? Still befuddled - probably missing something obvious.
0 Kudos
Message 10 of 10
(5,793 Views)