I’m looking into connecting some NCD wireless sensors that can output over TCP. The data packet will come in as hexadecimal bytes. I’ve learned all about their packet structure and how to perform the necessary math to convert it to real world numbers. I want to get a sense of parsing the data once Ignition has it before I make any purchases. Can anyone tell me where in Ignition I should parse the data (and how 
) This is what I’ve done so far…
I looked at some docs for that thing real quick and it seems like it’s not TCP, but rather some lower level protocol over wireless, and that you’ll need that little receiver dongle and drivers hooked up to the receiving PC at which point you can access the incoming data via a serial port.
Hmmm, I see what you are saying. They do have a gateway that receives the wireless data and relays it via Ethernet. It looks like the data packet is unaltered from what I originally posted. What do you think? I’m in new territory here. Thanks Kevin
I asked NCD about this, and they said the data packet would be the same as what I posted. So, I just need to figure out how/where to parse it as it comes in.
What is the rate the data is coming in?
You could setup a TCP device to receive the packets, then processing the incoming data with a Tag change script to process the hex into real value and write out the data you care about to other tags.
I believe the data rate is variable, meaning that I can change the rate. I would probably set them to something like a 3-5 min scan rate. One question though, the sensor gateway can handle multiple sensors at once, and the data packet has information about which sensor it is coming from. Is there a way to setup the tcp driver with multiple tags according to the source address, or setup a device per sensor. They would all listen to port 2101 so I would have to figure out how to filter the messages from only on sensor. Thoughts?
That’s plenty slow, I’d only be worries if you were going faster than like every 100ms. Just parse out the data to extract the source address.
You might have a tag structure like this:
- GatewayData
- 0A0A0A0A0A0A0A
- 0B0B0B0B0B0B0B
When data is received on GatewayData, you could parse the data, then write the value to the resulting value tag. system.tag.write(sourceAddress, ‘123.123’)
1 Like
That makes perfect sense. I believe I can make them work. If I can get the purchase approved, I will set them up and post the process in case anyone else would like to try NCD wireless sensors. Thanks Ryan.
IIRC, the TCP device munges all incoming data that is >7bit. Consider using direct java networking to open a listening socket and a thread to read bytes from it. Then use NIO ByteBuffers to read your raw data from the bytes.
I hope not, that sounds like more than I can handle. I guess I’ll just have to add it to the list of things to learn. The only problem is the list is getting longer, not shorter 
The TCP driver is written to deal with ASCII data, not arbitrary binary, and information is lost when non-ASCII binary is read into the String tag the driver exposes.
1 Like
@AlThePal I’ve seen you have dealt with this somewhat in other posts. Do you have any updated code or advice for opening a TCP socket/port listener? I would greatly appreciate it.
There’s a TCP driver for binary data on GitHub Generic TCP driver. It should fit your needs, but as it’s free and open source, there is no support.
2 Likes
Nice, I will give it a try. Thanks
Can somebody point in the right direction on how to simulate, if possible, a data packet coming in over TCP, so I can test receiving and parsing it?
I use socat for such tasks. Start with a binary file or files containing your encoded packets.
1 Like
I often use this driver to send data to printers. That data is regular text, but depending on the region, may contain special characters (accents).
It's a coincidence that for my projects in France, I had to use other protocols for communicating with printers (file drop and printing via a client interface).
But if I read that correctly, I wouldn't be able to use that driver for projects with TCP-driven printers when accents are involved. No matter what measures are taken in the printer or on the Ignition side?
Sorry, I should have said UTF-8 there instead of ASCII.
The only problem is when people try to turn the String payload back into binary data.
3 Likes
Might as well get to it. You're going to need a socket-level interface that yields raw bytes. And interfaces like DataInputStream and ByteBuffer will read multi-byte fields as integers and other data types for you. Don't re-invent the wheel.