Problem using serial port at same time as usb camera

[PatT]

Hi.

I'm using an old dll written in C, that communicates with a device ove serial port. I've written a .net wrapper using P/Invoke in C# that I've tested in C# programs. I'm calling my dll in labview using the .Net constructor and invoke nodes. It works well enough.

I'm also using the IMAQdx grab function to get data from a usb camera. That works too on its own. The problems occur when I try to open a comm port and then configure the camera (using IMAQdx open camera and IMAQdx configure grab) with the commport still open.

At one point when I was trying to debug this I got an error that said something like this:

"LabVIEW:  An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.

NI-488: Command requires GPIB Controller to be Controller in Charge"

I can't reproduce the same error, so can't provide a screenshot. Below I've posted some code examples showing what I'm doing. In the first one, everything works and the comm port closes properly and then the camera is configured and can grab. In the second after configuring the camera, when the comm port tries to close, the dll returns a "COMM_PORT_INVALID_HANDLE" error. After this, Labview has to be restarted before it will release the serial port for other programs to use. The only difference is the order of the operations, after the flat sequence, there is a while looop which is not shown that just does a continual grab from the camera.

working:

not working:

Can someone explain what is going on, and what can I do so that I can capture camera data and write to the serial port at the same time?

[mikeporter]

First comment is that you need to lose the sequence structures, they are unnecessary. You should be using dataflow to gate execution.

Second, are you sure that the two devices are on different ports. Many usb devices appear to the OS as using a serial com port.

The other option is that the old DLL doesn't play well with the other children...

Mike...

[PatT]

Is there a better way than a sequence structure to add a delay after each dll function call?

I'm fairly certain that the usb camera doesn't have the same identifier as the serial port. It shows up as cam0 in measurement & automation explorer, and there it is possible to have the camera do a continual grab whilst accessing the serial port. If its possible to use measurement & automation explorer to do a grab at the same time as the dll, I can't see why it shouldn't work.

[mikeporter]

The better way to handle delays is to create a subVI that is wrapper around the wait function and has all the same connections, except that it also has error clusters. Internally, you put a case structure aroung the wait function and tie the incoming error cluster to the selector node of the case structure. Put the wait function in the No Error caseand leave the Error case empty. The error cluster gets passed through the VI unmodified.

Insert this VI into the error chain where you want the wait to occur. Error clusters are an execellent way of establishing data dependencies.

In terms of your other questions, I'm not sure what could be wrong either. The point is that you should double check the settings and make sure everythign is still good. You also might try moving the serial IO to a different port as an experiment. Are you sure the "old dll" is mapping ports properly? If you specify a com port that you know doesn't exist, do you get an error? In the working versi0on of the code is the serial device actually fiunctional or does it just not return an error?

Mike...

[PatT]

I can't really move the serial port to a different comm port name, as the serial port is built into the computer. If I specify com2, which doesn't exist, the dll returns an error as you would expect.The serial device works correctly when being controlled by Labview. It only doesn't work when the labview code also tries to initialise a camera.

[mikeporter]

I don't know, it might be worth borrowing or buying a cheap USB/Serial dongle to give yourself another serial IO port for testing. Assuming that the DLL is behaving itself, there is no reason that they should be conflicting with each other.

Mike...

[ChrissyC]

---

@mikeporter wrote:

The better way to handle delays is to create a subVI that is wrapper around the wait function and has all the same connections, except that it also has error clusters. 

---

Another way is to install the openg toolkit. The toolkit includes a timing vi that is exactly as Mike describes (it's just done for you!)

-CC