LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview velmex

Just use a comma. 


C

PhD ChemE, CLD, Alliance Partner : www.interfaceinnovations.org
Message 41 of 52
(1,508 Views)
And then end each connactonated string with carriage return (for termination) or just forget that all together?
0 Kudos
Message 42 of 52
(1,500 Views)

No termination required. The configuration of the termination character (which is unnecessary with the code snippet above) just means that if the read operation sees a CR, it will assume the message is complete. It doesn't mean that your message to the controller requires a CR.

 

C

PhD ChemE, CLD, Alliance Partner : www.interfaceinnovations.org
Message 43 of 52
(1,492 Views)

Makes sense, thank you. Also what would you recommend for the timing delays?

 

Thanks,

Mridu

0 Kudos
Message 44 of 52
(1,459 Views)

Get a sense for how long it takes for the message to respond with a message and set the first delay a little longer than that.

 

I would guess that unless there is a major problem with the operation of the device, characters would be sent continuously.  But probably no more than the amount of time it would take to send 1 or 2 bytes between consecutive bytes in a message.  Since this is 9600 baud, that is about 960 bytes per second.  So a byte about every millisecond.  So a delay of a few milliseconds (several bytes worth of time) should be enough for the second part to be sure that the bytes have actually stopped being sent.

 

Another alternative to what I had shown is send your VISA write, don't have a delay, and in your first VISA Read, just read 1 byte.  Feed that into the shift register of the while loop.  So it will return as soon as it gets the beginning of the message no matter how short or long it is.  Then do the delays in the while loop and concatenate the new bytes at port onto thats string.

 

For your VISA timeout you set at the Serial Configure, the default is 10 seconds, which is rather long.  Figure out how long it takes for a response when there is the longest of delays and set your timeout value to be slightly longer than that.  I think about 2000 milliseconds would be sufficient if I had to guess.

Message 45 of 52
(1,417 Views)

Hi RavensFan,

I just tested teh first solution (the one you had given me yesterday). The motors run fine when I use it, but I am not getting any reading in either of my command indicators.. I have tried playing around with both the delays, and nothing is changing.. any ideas?

Thanks and regards,

Mridu

0 Kudos
Message 46 of 52
(1,385 Views)

I can only guess.  A couple questions I would have is did you ever get a response in the past using any version of the VI when using those particular commands?

 

1.  The device takes a command and acts on it, but never gives a response acknowledging it.

2.  A problem with the cable (or serial port),  where the the transmit line is working okay and the command is going out, but there is a problem on the receive line, the device is sending something back, but the data is lost on the way.

Message 47 of 52
(1,371 Views)

Hi RavensFan,

The response worked previously, when I only used the bytes at port (with about a 1000ms delay) and did not use the while loop.. The only thing I have added to that version is the while loop so somewhere in between, I guess the response is being lost..?

Thanks,

Mridu

0 Kudos
Message 48 of 52
(1,367 Views)

Something odd I see in your VI.  You aren't using the shift registers properly.  The VISA wire is coming in on a tunnel, going through, and put into a shift register, but the shift register as the beginning of the loop isn't wired to anything.  The VISA wire should be going through the shift register, not a separate tunnel.

 

Likewise for the error wire.  However, my opinion is that you should just about never put an error wire into a shift register.  Certainly never if you aren't doing any special error handling as a innocuous error in one loop iteration (s uch as a random timeout) will keep the code from ever executing normally again because that error keeps getting passed from iteration to iteration.  Most LabVIEW functions won't execute if there is an incoming error.  They'll just pass the error through.

 

I would put an indicator on the error wire to see if you are getting any errors.

 

Try increasing your wait times.  If you were getting a 1000 msec delay with bytes at port and is was working before, it should be working now.

 

I just saw the error, and I missed it on first glance.  You didn't wire the inner while loops like I did.  YOu aren't using the shift registers containing the string data.  You are getting nothing because you are only sending out the string data from the last iteration when there are 0 bytes.  You forgot to include the concatenation with the data that is in the shift register from the left side of the loop.

 

LabVIEW tip for you.  When putting in constants, just right click on the function input and pick Create Constant.  Now you'll have the constant of the correct type for the function (and its default value.)  That way you won't have the coercion dots like you do where you have a constant (I32) wired into the wait functions that expect a U32.

Message 49 of 52
(1,352 Views)

Hi RavensFan,

Thank you so much! I did not notice the improperly wired shift registers. Also thank you for catching the concattonating string error. One more question, is it possible to clear the command read after each time the program exits the while loop?

Also, thank you for the tip for creating constants!

Regards,

Mridu

0 Kudos
Message 50 of 52
(1,327 Views)