Asyncronous Thread

[nzwta]

We have a need to read a balance (scale) that is attached to a PC via a serial port and we need to see on the screen the mass (weight) as the mass changes in a "live" mode. The simplest means would seem to be opening an Asyncronous Thread to the port. This will allow the user top continue processing other stuff while the balance continues to dispay the "live" feed. The issue with this would be Asyncronous Threads take an additional licence and as we are using 60 workstations with balances attached that could be in this mode, the result could be expensive??

Is anyone out there doing anything similar elegantly and how have you got around the need for additional licences??

[murray]

There was a very similar posting recently in the General Discussion forum.

Do you really need multiple processes to achieve this?
Are you using JadeSerialPort?
Could you leave the serial port open and use timer events and/or asynchronous calls to poll it from the one process?
The concept is to have one process with everything being event driven. That way there are no blocking waits.
I must admit I have not used the JadeSerialPort class itself, so perhaps there is some limitation that does not allow that?
This is able to be done when using TcpIpConnection, which is also a subclass of Connection, so shares common concepts.

[allistar]

From what I'm reading each of the 60 workstations has it's own scales which are plugged into the COM port of that workstation. Using another Jade process per workstation will consume another CP, and cause an increase in licensing costs.

An alternative is to not use JADE to read the COM port. Use an executable (developed in your language of choice. C+, C# or whatever). This reads the COM port and then communicates this back to a single JADE process running on the database server. This in turn sends an event to the client workstation telling it that there is a new reading. The external app could communicate with the single Jade server process using either TCP/IP or something nasty like file I/O which the process running on the database server polls. How effective these solutions are depend on how realtime you want the weight information updated to the client. This shoud save JADE license costs though.

[murray]

My reply was questioning the need for multiple Jade processes on each workstation.
If the I/O to the scale is reasonably quick (fractions of a second), then you can use one single process driven by events.
However if the I/O takes many seconds, then this could introduce unwanted lag / unresponsiveness in the client application.
Maybe the original application is using blocking calls, but the need for this requirement should at least be questioned.

[murray]

By the way, as I understand it, when executing asynchronous calls on a Jade Connection subclass (e.g. TcpIpConnection, etc) Jade itself uses additional threads but no extra processes.
We have large numbers of asynchronous TcpIpConnections in one application (single Jade process) with a correspondingly high thread count. However, there are no extra processes shown in Jade Monitor.

[nzwta]

Thanks - I am now questioning the original premise and will get back to you when I can confirm we are using an additional process. And will check the use of JadeSerialPort.

[murray]

Yes, you need to differentiate between processes and threads, especially as used by Jade.

Jade's Asynchonous Method Calls require additional Jade processes that are started as applications (Asynchronous Worker Applications). You will see them separately in Jade Monitor sharing the same Node. These will use JadeMethodContext instances and be started with app.asyncInitialize(). These will consume multiple Jade licenses (I presume).

I believe Jade's TcpIpConnection (and probably JadeSerialPort) asynchronous methods use separate threads internally. They don't require multiple Jade processes. I don't think you can see these in Jade Monitor; Windows Task Manager is probably required. These calls will be such as: openAsynch(), closeAsynch(), readBinaryAsynch(), writeBinaryAsynch(), etc. They will have callback methods defined to handle the events that result.

[Dr Danyo]

Hi Allistar,

I'd do something similar but rather than create an executable I'd create a .net assembly, which I would consume directly into JADE using the JADE .net class library feature, as this can also receive .net events, I would design my wrapper assembly to invoke an event when the reading takes place, then once consumed into JADE I would implement the event. I've used this approach in the past when working with 3rd party telephony software and found it to be a very straight forward approach.

This design means you can hide the implementation of talking to the hardware (a bonus if the comms is quite low level) away from JADE as well as design a domain api that uses native JADE to connect rather than tcip or flat files.

You would also need operations to start and stop reading, but it should be simple enough.

- Dr Danyo.

From what I'm reading each of the 60 workstations has it's own scales which are plugged into the COM port of that workstation. Using another Jade process per workstation will consume another CP, and cause an increase in licensing costs.

An alternative is to not use JADE to read the COM port. Use an executable (developed in your language of choice. C+, C# or whatever). This reads the COM port and then communicates this back to a single JADE process running on the database server. This in turn sends an event to the client workstation telling it that there is a new reading. The external app could communicate with the single Jade server process using either TCP/IP or something nasty like file I/O which the process running on the database server polls. How effective these solutions are depend on how realtime you want the weight information updated to the client. This shoud save JADE license costs though.

[murray]

From what I'm reading each of the 60 workstations has it's own scales which are plugged into the COM port of that workstation. Using another Jade process per workstation will consume another CP, and cause an increase in licensing costs.

An alternative is to not use JADE to read the COM port. Use an executable (developed in your language of choice. C+, C# or whatever). This reads the COM port and then communicates this back to a single JADE process running on the database server. This in turn sends an event to the client workstation telling it that there is a new reading. The external app could communicate with the single Jade server process using either TCP/IP or something nasty like file I/O which the process running on the database server polls. How effective these solutions are depend on how realtime you want the weight information updated to the client. This shoud save JADE license costs though.

Hi Allistar,
I'd do something similar but rather than create an executable I'd create a .net assembly, which I would consume directly into JADE using the JADE .net class library feature, as this can also receive .net events, I would design my wrapper assembly to invoke an event when the reading takes place, then once consumed into JADE I would implement the event. I've used this approach in the past when working with 3rd party telephony software and found it to be a very straight forward approach.

This design means you can hide the implementation of talking to the hardware (a bonus if the comms is quite low level) away from JADE as well as design a domain api that uses native JADE to connect rather than tcip or flat files.

You would also need operations to start and stop reading, but it should be simple enough.

How is this simpler than keeping it within Jade and using JadeSerialPort ansynchronously (within a class wrapper, if necessary)? Is there some reason to avoid JadeSerialPort in general? My only similar experience is with Jade's TcpIpConnection, which works fine asynchronously, in one process. Both are subclasses of Connection.

[Dr Danyo]

Hi Murray,

My response was in relation to the approach of creating a third party application (executable vs assembly).

Likewise I've had no experience using the JadeSerialPort class, my own personal experience (and preference) is that it can be easier integrating to third party appliances by using a .net library rather than writing the integration in native JADE (often a library already exists and its just a matter of importing it and using it), especially the case if the 3rd party hosts wcf services etc.

That being said, the asynch features of the TcpIpConnection class work great and the JadeSerialPort class should be a good fit for this problem.

- Dr Danyo.