problem with visa serial comms

[sarj]

I am having some problems communicating with a laser driver using labview 7.

The attached code, occasionally works to some degree and a previous version completly once.

The problem seems to be that when signals are sent to the laser driver some corruption is occuring which causes it to hang. switching off and back on is the only way to restart comms.

I have tested the output by connecting up to hyperterminal on another PC, and this seems to produce identical results to the suppliers C++ s/w.

Starting hyperterminal, turning on the laser, shutting down hyperterminal and then running the labview code allows some comms around 25% of the time, even then its only for a short period.

The labview prog is designed to send amplitude and frequency info to the laser driver and the read in resultant data through a NI USB DAQ. The DAQ stuff appears to work fine.

The sliders are used to control both freq and amplitude, until the data logging button is pressed, when a for loop controls the freq data.

laser control codes -

channel select - cx        1 in this case

amplitude         - axxx     0-100

frequency         - fxx.xxx  85.000 - 130.000  (can't have more than 3 digits after the decimal point)

Can someone tell me how to get this working reliably  thanks

[sarj]

I should also say that after each code is sent a carriage return is also required and an OK is received from the device, hence the VISA read vi's.

[Odd_Modem]

For one thing I would remove the 'wait for front panel activity' function, or incorporate it into the data flow of the visa reads and writes by putting it in a sequence structure and wiring the visa error cluster through the frame.

[unclebump]

You have some terminals left open on the Visa Configure Serial Prt vi. I would set them to match the laser system settings. I wouldn't assume the default values will work. Also, I usually concatenate all of the command string and transmit with one Visa Write block.

[mikeporter]

Another possible reason for the erratic behavior could be sending a command with an invalid delimiter (like the place in the code where you send a line-feed instead of a carriage return).

Hint: when typing within LV on a Windows machine, pressing the "Enter" key gives you a line-feed, not a carriage return.

Next, does the value following the "a" command need to be three digits? For example, for the value 10 do you have to send the command "a010" or can you just send "a10"? The code you have will generate the latter, the format string "a%03d" will produce the former.

Finally, a much more efficient way of generating the "f" command is with the format string, "f%.3f" and drop all the manipulation to the string after the formatter.

Mike...

[sarj]

Thanks guys

odd_modem & unclebump - suggestions made no difference, unfortunatley, also couldn't work out how to wire a wait into the visa string.

mike porter - I didn't realise about the line feed, so will give it a try. I did try the f%.3f, that altered the front panel display but the string sent out of com1 was still xx.xxxxxx. not a neat solution but it did work.

I have a cut down version working, enough to do some testing with. Its now a one shot program that only deals with the scan. Its reasonably reliable. It opens the DAQ & VISA then runs the FOR loop,tx VISA, gathering DAQ and saving data to file, I was thinking that the problem could be with the CASE or WHILE constructs. It also seems that the VISA close causes the laser driver to hang therefore the device needs to be reset after every run.

[mikeporter]

Please repost your modified code. If you are using the formatting string I gave you and are still getting a result showing 6 decimal places you don't have something hooked up right.

Mike...