Poll COM port continuously on gateway

Ignition
1

Hi everyone,

We have some Mitutoyo wireless caliper measurement devices that can wireless transmit measurement readings into a USB receiver unit.
PDF Brochure here.

Sounds like the USB receiver unit could be connected to an Ignition gateway computer, and we could read values from it using the system.serial functions

But it doesn’t sound like those functions can be setup to constantly poll and listen for new data on the COM port? Or am i mistaken?

The end goal is to have a Perspective View that can have a table visible that has data automatically populated in it based on new measurement readings from the caliper unit.
Then an operator can review all the measurements, and click some button to save the measurements to a SQL table.

2

No, you’re right. I think at best you could try a timer script with a dedicated thread that reads and updates a tag with data.

3

I always use a dedicated thread that stays on the port read. Minimal parsing then throw over the fence to one or more tags.

4

A dedicated Gateway timer script? How do you keep the port read open though?
I just noticed the “Timeout” parameter on these scripts is optional. Presumably if you don’t enter a value, it doesn’t time out at all?

5

You wouldn’t want to keep it open with a timer script… I think Phil is suggesting something like:

  • in a startup script, spawn a thread that opens the port and enters a loop reading it
  • when it reads data put it into a tag
  • in a shutdown script somehow signal that thread/loop it needs to break and close the port

Our scripting lifecycles make this kind of stuff tricky and dangerous unless you really know what you’re doing.

I’d personally feel more comfortable writing a small custom module to communicate with this thing.

6

Also, before you really get any further… have you confirmed this USB device even presents itself as a virtual COM port? I can’t find any mention of that in the document you linked.

1 Like
7

Thanks Kevin,
Yea that gateway scripting doesn’t really sound like the route we want to go down… Module might be a better move.

I haven’t actually confirmed how it presents itself to the server. Unfortunately I am not able to get on site to do any testing so can only pass on their findings.
I’ll get them to connect it to a server and see what we can do with it.

8

We have a weighing scale feeding data over 485 port as ASCII string.
We used a 485 to USB converter hooked up to a RPI4 where a daemon opens up and keep the com port open forever. When the weighing scale transmits any data, the daemon reads it, parse it and insert any relevant info into a database.
Ignition just reads the database and generates reports or export to excel etc.

9

Interesting, thanks for the feedback. Reading data from a database is certainly a good way to go, and makes it relatively easy to keep track of what data Ignition has read, and subsequently processed.

The client had tried writing a custom bit of software in .NET which runs on the PC the receiver is connected to, and have that send UDP messages to the ignition gateway.
But they are keen to try not to introduce additional software / hardware complications that require new technology outside of what the Ignition gateway is providing.

So i was hoping to find a solution that involves managing everything in the Ignition environment.

10

A dedicate gateway thread with lifecycle management really isn’t that hard. (Use system.util.getGlobals() or system.util.persistent(), the latter from my free LifeCycle module.)