LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

serial port: Input/output signal errantly combined

Solved!
Go to solution

If every message coming from the device ends in the hex 04, then that is what you want to use as the termination character.  Putting in the U8 constant 4 should work.  (The default value is 10 decimal or 0A hex which is a new line character).  Did you remember to change the boolean constant to True to enable the termination character?

 

This issue with the p and t has me puzzled.  As you describe it, it sounds like the command is getting stuck in the write buffer until something else happens such as closing the com port.  You may want to try adding a function to flush the buffer, and set the input mask so that it flushes the write buffer right after you write the data.  It shouldn't be necessary.  I have yet to come across a situation where I needed to do it.  But it is worth a shot.

0 Kudos
Message 11 of 17
(1,279 Views)

I cannot get the VISA Configure Serial Port vi to use the termination character at all.  The boolean is changed to True and the the termination character is a U8 with the value of 4.  I can see the h04 in every line of data transmission and the manufacturer indicates this is the end of line.  The bytes read function tells me that I am getting more than 25 bytes a sample when I try it this way, without the time delay in the beginning of my loop.  I am unsuccessful using anything BUT that time delay.  Is there anything else you can think of to correct the termination character?

 

I followed your suggestion of flushing the buffer (changing the mask appropriately) with no change in performance.  Here's an interesting kink though - if I take the VISA Close command and place it inside the loop, just after the flush buffer command, then I get the mag light turning on, then off, every second (equal to the time delay of the loop).  So yes, I think there is something to the idea that the command isn't getting sent until the port is closed.  what's even more interesting is that the 'p' command works properly this way - properly means turning the mag light on and off, not properly means when the instrument mistook the 'p' command for a 't' command and toggled the LED lights. 

 

I'm stuck.  I'll hope that NI Spy can reveal something- where can I find this?  If there is anything more you can think of please let me know, because as far as I know, all the logic is correctly in place, without the results.

0 Kudos
Message 12 of 17
(1,260 Views)
Solution
Accepted by topic author CodeMunkee

NI-Spy is installed with LabVIEW.  You can find it under the Start Menu / National Instruments software.

 

What kind of serial port are you using?  Is it a real port in the PC, or is it a USB/RS-232 adapter port?  I've basically had success with USB adapters, but I have seen many posts where certain brands don't just quite work right for some people.  You may want to search the forums on this topic.  If this might be the case, see if you can try it with a hard RS-232 port if you have one available on your PC.  Or another brand of USB/RS-232 adapter.  I've used IOGear brand successfully for a couple years.  Though interestingly, I just had a situation where the driver was causing a crash on my PXI-8196 computer.  Fortunately, upgrading to the latest driver fixed it.

 

At roughly one cycle a second, you might be able to go ahead and close your port at the end of each second, or just when you need to send the p byte and repopen immediately.

 

You could also handle the termination character on your own.  Collect the input buffer and append it to a string that you carry from one loop iteration to the next in a shared variable.  Search the string for the character.  If you find it, write out the string and put the remainder of the string back in the shift register.  Exit the loop to send the found string to the rest of the code.  You would create your own timeout to this loop that exits the loop and returns what you have in the event the hex04 character you are looking for never shows up.

0 Kudos
Message 13 of 17
(1,253 Views)

Yes I am using a USB/RS-232 adapter, one that I have had luck with in the past, but perhaps not now in the present!  I do have a hard serial port on this machine, I'll try that.  I'll see what the other forums have along those lines.  The termination character is a mystery to me, but not a game-breaker at this point.  If it becomes one, I'll follow your advice for doing it manually. 

 

Thanks for sticking with this so long.  Go Ravens.

0 Kudos
Message 14 of 17
(1,250 Views)

CodeMunkee wrote:

 

Thanks for sticking with this so long.  Go Ravens.


Smiley Happy

 


CodeMunkee wrote:

Yes I am using a USB/RS-232 adapter, one that I have had luck with in the past, but perhaps not now in the present!  I do have a hard serial port on this machine, I'll try that.  I'll see what the other forums have along those lines.  The termination character is a mystery to me, but not a game-breaker at this point.  If it becomes one, I'll follow your advice for doing it manually. 


If it turns out to be a problem with the adapter, then perhaps the termination character part will sort itself out.

 

Out of curiosity, what brand of adapter are you using now?

0 Kudos
Message 15 of 17
(1,245 Views)
It is a CablesToGo USB to Serial Adapter.  I'm pretty sure I'm using DB9 (and not DB25).  There are plenty of bullet points on the packaging that indicate this adapter will turn water into wine (without actually saying anything helpful).
0 Kudos
Message 16 of 17
(1,240 Views)

This is a cross-post for the benefit of Raven's Fan in reference to the puzzling 'p' command dilemma....

 I believe this will clear up much of the mysterious behavior.  Perhaps you are familiar with how to handle it from here?

 

~~~~~~~~~~~~~~~~~~~~~~

Thanks for your words of encouragement and the suggestions.  I have found another wrinkle.  Please be advised, I am translating from Forth code, and prior to this script did not even know Forth existed (at one point in time). 

 

To the point- it turns out that the 'p' command is supposed to talk directly to the Modem Control Register.  I need to send a binary signal 00000011 to the MCR in order to turn the mag light on.  As I understand it, this activates the DTR (Data Terminal Ready) and the RTS (Request To Send).  Then I'll obviously have to turn it off at some point, so I'll send a binary signal of 00000000.  This is all done as a U8 I assume, so I would send a U8 '3' to turn on, then U8 '0' to turn off.

 

At this point, I am out of my LabView league.  I have found a command called VISA Poke 8, but applying it the same way (but in conjunction with VISA Map Address) as the VISA Write does not work any differently than before. How can I control the Modem Registry Control?

 

Thanks for your help! 

0 Kudos
Message 17 of 17
(1,213 Views)