Asyncronous Thread

Forums for specific tips, techniques and example code
nzwta
Posts: 13
Joined: Thu Sep 10, 2009 12:46 pm
Location: Napier

Asyncronous Thread

Postby nzwta » Thu Jun 21, 2012 12:24 pm

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
Posts: 144
Joined: Fri Aug 14, 2009 6:58 pm
Location: New Plymouth, New Zealand

Re: Asyncronous Thread

Postby murray » Thu Jun 21, 2012 1:54 pm

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.
Murray (N.Z.)

allistar
Posts: 156
Joined: Fri Aug 14, 2009 11:02 am
Location: Mount Maunganui, Tauranga

Re: Asyncronous Thread

Postby allistar » Thu Jun 21, 2012 2:13 pm

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
Posts: 144
Joined: Fri Aug 14, 2009 6:58 pm
Location: New Plymouth, New Zealand

Re: Asyncronous Thread

Postby murray » Thu Jun 21, 2012 2:20 pm

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 (N.Z.)

murray
Posts: 144
Joined: Fri Aug 14, 2009 6:58 pm
Location: New Plymouth, New Zealand

Re: Asyncronous Thread

Postby murray » Thu Jun 21, 2012 4:02 pm

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.
Murray (N.Z.)

nzwta
Posts: 13
Joined: Thu Sep 10, 2009 12:46 pm
Location: Napier

Re: Asyncronous Thread

Postby nzwta » Fri Jun 22, 2012 11:27 am

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
Posts: 144
Joined: Fri Aug 14, 2009 6:58 pm
Location: New Plymouth, New Zealand

Re: Asyncronous Thread

Postby murray » Fri Jun 22, 2012 11:47 am

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.
Murray (N.Z.)

User avatar
Dr Danyo
Posts: 56
Joined: Fri Aug 21, 2009 8:59 am

Re: Asyncronous Thread

Postby Dr Danyo » Mon Jun 25, 2012 8:08 pm

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
Posts: 144
Joined: Fri Aug 14, 2009 6:58 pm
Location: New Plymouth, New Zealand

Re: Asyncronous Thread

Postby murray » Mon Jun 25, 2012 10:21 pm

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.
Murray (N.Z.)

User avatar
Dr Danyo
Posts: 56
Joined: Fri Aug 21, 2009 8:59 am

Re: Asyncronous Thread

Postby Dr Danyo » Tue Jun 26, 2012 3:27 am

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.


Return to “Tips and Techniques”

Who is online

Users browsing this forum: No registered users and 14 guests