My code works when i highlight and run the program and when not highlighted it dosen work.

[ann]

Hey I have been working on a interface to make some valves work.I have hooked up the hardware to the RS485,and com4 port of the com and I have created a code to make the valves work , however when i try checking if the valves r in the right postion (a part of the main code), it dosen work.

its like this (i am explaining ti a bit since i gss u need to know abt how the hardware works inorder to help me).

to send a valve to a postion: the code to send to teh device is

/L GO 5 (i.e u r sending valve with id L to position 5)

similarly to obatin the current positon of the valeve u have to send to the device

/L CP (i.e what is the current position of valve with id L). the output of this is

L Position = 5.

(I have attached the code that i have written to check the valve postion, bt somehow when i run the program it dosen work, however when i highlight in the block diagram page to see the program flow, then the program works)

can anyone suggest why is it so, and has anyone come across a problem where the program as such dosen work, but when u highlight it it works, and since it works when highlighted i can't even detect where the problem is, to debug it.

Download File:post-5239-1150847687.zip

Download File:post-5239-1150847670.zip

[Phil Duncan]

Hi ann, welcome to LAVA.

I have run into similar problems before and have read other threads about this as well.

The first thing I noticed is that you were not closing the VISA reference after executing your code, this leaves an open reference to the COM port and may result in an error when you try to run your program next time as the VISA resource may still be considered "open" from the previous execution of your code.

Some serial instruments have some intelligent handshaking codes to verify when a command has ben executed, others don't. I have found that if you can't determine when the instrument has executed a command, insert a short delay between writing and reading to/from the COM port. It's not elegant but it works 90% of the time.

I have attached an image of a suggested solution to try. Without the instrument attached it is a bit difficult to test though.

Cheers & Beers

:thumbup: & :beer:

[didierj]

Some serial instruments have some intelligent handshaking codes to verify when a command has ben executed, others don't. I have found that if you can't determine when the instrument has executed a command, insert a short delay between writing and reading to/from the COM port. It's not elegant but it works 90% of the time.

Agree.

I haven't seen the code (since I don't owe LV8, only LV7.1), but a frequent problem when performing serial/GPIB/... communication is speed or better slowness of the port. Make sure you have either (like Phil described) delays inserted or have set port timeout long enough or (if applicable) have set termination character. There must be demos in the examples (also include the online examples from in the example browser).

[ann]

Hey Phil, thanx a ton, it did work,i tried using the delay loop before but i gss my main problem was closing the VI.I really appreciate you replying back.Thanx again

[ann]

HI Phil, I tried incorporating this in the larger part of the code that i had developed adn same problem, works when highlighted,I have attached my code.

there are 5 valves have 8 outlets and the dials r used to indicate which postion teh valve is currently in.

Download File:post-5239-1150940400.zip

Download File:post-5239-1150940423.zip

Download File:post-5239-1150940436.zip

Download File:post-5239-1150940450.zip

Download File:post-5239-1150940466.zip

[Phil Duncan]

ann,

Some of the required fils are not included in you post. Regardless, I think the problem is in the writeserial 4.vi. You may need to carefully review the code to ensure that you close every VISA resource that gets opened. Using a VISA global vi as you have is not a bad way to do it but you must be quite vigilant about what references (VISA or otherwise) that are open/initialised and how (& when) the application closes those references.

For instance if your main VI calls the "Init" mode of writeserial 4.vi twice with the same settings, the second call should produce an error as that port is already open. This is more likely to occur when reading/writing though. There are two main schools of thought on how to handle this type of resource access as it is functionally identical to file I/O.

1) You open the VISA resource with an init type function and maintain the reference in a shift register (or other repository), perform all reads and writes to the VISA resource and close it when the application is complete. This may improve performance but you run the risk of leaving COM ports open if your application crashes before closing the VISA resource. You must ensure that ALL VISA resources are closed when they are no longer required.

2) Your application controls the VISA resource as follows: open->read/write->close any time it needs to communicate. This ensures that VISA resources are handled appropriately and minimises the chance of a COM port being locked out by LabVIEW causing problems on subsequent executions. This method will no doubt incur a perfromance penalty as serial devices often require a finite time to establish communication though.

Sorry if I am regurgitating stuff you already know.

Cheers & Beers

:thumbup: & :beer:

[Neville D]

ann,

Some of the required fils are not included in you post. Regardless, I think the problem is in the writeserial 4.vi. You may need to carefully review the code to ensure that you close every VISA resource that gets opened. Using a VISA global vi as you have is not a bad way to do it but you must be quite vigilant about what references (VISA or otherwise) that are open/initialised and how (& when) the application closes those references.

2) Your application controls the VISA resource as follows: open->read/write->close any time it needs to communicate. This ensures that VISA resources are handled appropriately and minimises the chance of a COM port being locked out by LabVIEW causing problems on subsequent executions. This method will no doubt incur a perfromance penalty as serial devices often require a finite time to establish communication though.

Sorry if I am regurgitating stuff you already know.

Cheers & Beers

:thumbup: & :beer:

You can also select under:

TOOLS Menu>Options>Environment>Automatically Close VISA sessions.

This will close VISA sessions when the top-level VI goes idle.

It is a good safety net in case you forget to close all VISA refs in your code.

Neville.

[Karlos]

I think you need put each VISA command inside a sequence frame then you will use 3 sequences frames one for visa clr other for visa write and the final for visa read... i think i use this solution with an old problem like this and it works...

[ann]

Thanx, Phil, Neville and Karlos for your prompt replies.I really appreciate u guys taking time off to go thru my extensively looong code:).Phil, the whole day i tried (with my limited knowledge) to make sure i closed all teh VISA ports and well i wasn sucessful.Neville and Karlos, I will try ur solutions tom and get back to u.the option Neville gave sounds pretty cool, hope it works.

[didierj]

...inside a sequence frame...will use 3 sequences frames...

Uhh...

Sequences only serialize the execution of the primitives/sub-vi's. BUT since the VISA-primitives have error-in/-out, use them to serialize operation. As a bonus, subsequent operations will be skipped, if an error occurs somewhere.

Heavy use of the sequence structure is considered as bad wiring, better use Error-cluster, or (if appropriate) just let independent tasks run in parallel.

[ann]

Hey Neviile, i did try what u suggetsed and the funny thing is the valves change postion twice (i.e 2 cycles) and then the alarm goes off and i did try Karlos's idea too, but i gss i incorporated it in the wrong way and it din work, anyways gss I will have to ask someone to see my code with the device attached and debug it. Thanks guys for ur thoughts.