Issues about applying "parallel tasks" with serial serial port

[Slyfer]

Hi all,

I'm doing a routine (vi) that is intended to be used for calibration of 3 temperature probes of a temperature controller device (TCD), in parallel
TCD has a serial port, I can communicate with successfully using a low level routine that implement Modbus protocol functions and use the VISA serial VIs.
I can read/write some registers that adjust the temperature value.
So, for example, if you have 30 °F on display of TCD, and calibration register is -1, you can modify it (with a known formula) to 4, and the temperature will be 32°F.

I wrote a routine that works, and it's called "Cal.probe", it works for 1 probe, and it follows the state diagram in FIG.2 (attached).
I would like to call this function in a "parallel" way, see FIG.1 where I pass parameters that I need.

ISSUE 1)
The inner serial functions for serial communication are NOT "reentrant", they weren't make with "parallel tasks" in mind...
If I declare the single "Cal Probe" VI as REENTRANT, I see that they are called and run ALMOST at the same time (verified enabling the "open vi when called" and "close if origially closed" options), instead it is not reentrant, the same function is not called in parallel so I lose the advantages of LabView hassle-free multithreading (it's called and executed, then called again and executed, ecc..)

Is this correct?

ISSUE 2)
All the instances works with the SAME COM port, but if reentrant, they work in "separate memory enviroinment".
What problems can arise? Is this approach correct? a better approach in design?
The inner serial function is made like this (EVERY time it's called do this):
1) initialize serial port
2) send modbus packet to write buffer of PC
3) waits and poll the receive serial buffer of PC because a modbus packet response will be received (otherways has a timeout error and/or retries)

This implementation is correct in your opinion? I tried that in different project and it works, until now I've never read/write data of other registers, because it seems there is a inner queuing system in the VISA, and probably they keep track the "owner" of the data requested

Message Edited by Slyfer on 04-17-2008 04:21 AM

[GerdW]

Hi Slyfer,

you only have one COM port - how do you want to perform simultanous (parallel) communication???

Either you put the 3 COM accesses into one (I'm not familiar with modbus, can you read/write several registers in one access?) or you have to check the modbus in sequential order (ask for register1, read register1, ask reg2, read reg2, you get the scheme)...

[Slyfer]

By "parallel communication" I mean (my goal) "independent communication".
I try to explain better what I'm trying to do.
If you have a routine R that does a task using 1 serial COM port and a set of parameters P_1, and you must invoke the same routine for other 2 different set of parameters P_2 and P_3, what can you do?

Solution 1 (serialization approach):
You call R passing P_1, then R passing P_2, then R passing P_3.
You call R three times in sequence (slow .... )

Solution 2 ( correct? )
Consider that each routine R is independent (it doesn't use global variables, so I don't have the problems of dealing with semaphores, because I don't risk to write/read a variable from two different points), and consider that R is described (implemented) by the state machine in FIG2.
So each instance of R runs on it's own state-machine.
Inside each R, there could be some calls to the serial write/read VISA... but there is a timeout waiting the response, example:
modbus_read(register_1) = init serial port + send_modbus_packet_request_to_outSerialBuffer + read the response (retry&timeout protocol)

Is it possible that meantime, another process (the same R also!?), get access to the serial port and queues another modbus request???

Only function 3 and 6 of modbus protocol are available:
3 = read one single register
6 = write one single register

So in your opinion this is impossible? I think it's possible, otherways the whole ModBus chain over RS485 would be impossible to do ( = multiple devices sharing the same COM port, access to this common medium is ruled by Modbus protocol state machine,all device receive the packet_request, but only the one which match the address responds). This is the scheme:

PC + COM1 < --- Modbus over serial line RS485---->> DEV 1 (addr=1) + DEV 2 (addr.34) + DEV 3 (addr.22) + .... etc... 

[GerdW]

Hi Slyfer,

"Is it possible that meantime, another process (the same R also!?), get access to the serial port and queues another modbus request???"

I would say YES. There is only one COM port, but 3 routines are trying to access it. Surely they will interfere with each other...

Btw. you only have to init the serial port once at the start of your program!

[Slyfer]

I initialize and close the VISA resource every time I call the read_register / write_register routine to achieve this behaviour:

it is possibile to have 2 distinct exe files that use the same port at the same time, without conflict.

If you have a program that at the beginning initializes one COM (to use it only sometimes in the program, not continuosly), and then you build it, you have an application that will reserve that COM for itself.
But if you need an extra instance of this program (so two exe running in parallel) and you want to use it on the same COM, they will conflict.
The approach is to initialize/opeon/close practically on demand...
I don't know if there are better ways to do this, but what I said is proven and working (even if I don't fully understand how )

But this brings to me another question about the topic:
In this last case (2 exe running, the same program opened two times, just copy paste his folder elsewhere) opening/closing on demand the same COM port, how are they handled in case of simultaneous access to the COM?
Is the OS (multithreaded) that seemless time-shares the resources, letting resolve one or the other application access to the COM???

Message Edited by Slyfer on 04-17-2008 09:27 AM

[GerdW]

Hi Slyfer,

what kind of OS?

Well I doubt this will work as I told before: only one resource that cannot be shared. Imagine this scenario: 2 processes start serial communication. Both request values of certain modbus registers, the both are waiting for an answer. Which process gets which answer? How do they know it's the answer to their request? What happens when they read the answer and then they find out it's not the correct one?