com port control via a dll

[Akiel]

Our problem consists of LV2010 calling a dll written in cvi. The dll is to control a thermal chamber via rs232. At present its at very early stages, basically it opens the com port, returns a value dpendant on a numberical input then closes the port. This is being called from labview via a call library function. (in a while loop with a 10ms delay, call 2 library functions). What is happening is the port is being opened fine, some comms is happening as expected but the dll is not returning control to labview. Can anyone offer suggestions for a possible cure? Sorry if this should be on the CVI board but as its a crossover subject hopefully someone here can offer some advice.

Many thanks in advance 

[smercurio_fc]

Clearly the DLL call is not completing, which is why LabVIEW is "stuck". As to why it's not completing, you'd have to look at the way the DLL works. Since you haven't provided any information about the DLL, I don't know what more you can expect anybody to say.

Aside: why are you using a DLL to do this as opposed to simply using VISA to do the serial communication. What's so special about this DLL?

[Akiel]

the dll is not vital its done that way but we are doing that way because of resource management (my collegue is a cvi programmer) and I can interface with dlls quite easily.

He did find the fault, its similar to the use of a simple while loop in labview with no delays in where by it it takes over the cpu. I forget the exact command but allows the system to process some events. This meant the processor wasnt getting bogged down and so my LV code had control again and i could quit out of it correctly.

i was just looking for some pointer as at the moment its a very bare bones dll, (pass in a number, perform numberic tests, return value)  so there wasnt much info i could pass on

[rolfk]

Unless this thermochamber is a very complex thing and the driver is going to do a lot of involved logic itself, I'm pretty sure you will gain nothing in terms of time, by replacing the effort to program VIs to communicate with it, with VI's that call the DLL driver. And you complicate everything by involving someone else into this project who is using a different development environment that you can't do anything in yourself. So if something doesn't work you will always have to wait for him to debug it for you, also while he is out of town or in vacation.