Reading/Writing Multiple Serial Inputs and Outputs using NMEA protocol

Ignition
1

Hi,

We have a project which requires to read 16 serial inputs in NMEA string and displays the information from each input onto a mimic page. We are also required to process these information and output them to 42 equipment in NMEA string. Each on the input and output has to be configurable for selection on the com port no. , baud rate, message type and update frequency.

As we are using ignition for the mimic pages as well as the back-end works (ie configuring the serial ports, scripts for reading and writing nmea strings), we would like to understand what are the constraints and limitations to achieve our requirement.

For the configuration on the comport, we have attached the scripts in the text file and the mimic of the configuration page. We would appreciate if anyone could suggest a better way to make the scripts much more elegant.

Script for InputConfiguration.txt (9.3 KB)

2

You might find this post helpful:

3

I have a few clarification on the below script from clientserial.py:

if otherThreadName:
tcEstimate = Thread.currentThread().threadGroup.activeCount()
threads = jarray.zeros(tcEstimate*2, Thread)
threadCount = Thread.enumerate(threads)

  1. What does it do ?
  2. What is the rationale of multiplying tcEstimate by 2 ?
  3. Is there a good reference to understand the threading concept used here ?

The monitorToledo(ctPath, myThread) function has 2 arguments but are not called anywhere in the clientserial.py script. I wonder why is it so and how will then clientserial.py works.

I have tried to run the script by using a button component with the following script in the actionperformed event handler:

system.tag.write("[Client]SerialThread/Port", ‘COM11’)
project.clientserial.background(project.clientserial.monitorToledo, “SerialThread”)

The moment i clicked onto it in preview mode, ignition seems not responding. However, my task manager shows that it is still running.

Any idea why is it so :confused:?

4

See the Java documentation for Thread.enumerate(). The purpose is to relatively reliably iterate through other threads looking for a matching name. So it can be killed off.

It is called from background as callable. You should expect to write a suitable monitor*() function that suites your protocol requirements.

That's because background() must be called from a background thread, such as from invokeAsynchronous(). I should document that a bit better. In my actual usage of this code, I use the callAsync() function from later.py to wrap that for me: