How to work with data from TCP driver

Thanks Step7 and Thanks Colby that sounds really promising. I’m looking forward to trying both. I’m actually a little amazed that anyone one has a use for barcode readers and other things (check weighers in my case) without knowing that a new signal has arrived to count or make a decision etc. :scratch:

I am surprised we haven’t heard of this before. I think a lot of serial to ethernet devices send empty strings or special strings if no signal. So, every time a new one comes there is value change.

Hi Brett,

All of the barcode or scale usages that I know of simply make use of the change of data value itself, or user intervention. That is, in the cases I’m thinking of, either the fact that the same exact event might happen twice in a row isn’t a concern, or the data is being used as a “realtime” tag on a screen, which then has a button to store to db, after the operator confirms it.

Doesn’t mean there’s anything wrong with what you want, it just hasn’t come up yet.

Regards,

Step7, I tried your script but it returns the following error in the console message:

emUtilities$3$1-AWT-EventQueue-0] Error running function from fpmi.system.invokeAsynchronous
Traceback (innermost last):
File “event:actionPerformed”, line 18, in doAsynch
NameError: d

at org.python.core.Py.NameError(Py.java)
at org.python.core.PyFrame.getglobal(PyFrame.java)
at org.python.pycode._pyx20.doAsynch$1(<event:actionPerformed>:18)
at org.python.pycode._pyx20.call_function(<event:actionPerformed>)
at org.python.core.PyTableCode.call(PyTableCode.java)
at org.python.core.PyTableCode.call(PyTableCode.java)
at org.python.core.PyFunction.__call__(PyFunction.java)
at com.inductiveautomation.ignition.common.script.ScriptManager.runFunction(ScriptManager.java:403)
at com.inductiveautomation.factorypmi.application.script.builtin.ClientSystemUtilities$3.run(ClientSystemUtilities.java:265)
at java.lang.Thread.run(Unknown Source)

This is way beyond my current knowledge but I am giving it a go so if you could help I would appreciate it. As you probably read on this topic, Inductive are hoping to sort out my issue with the TCP driver but I am still going to try your method. Must buy “Jython for Dummies” at the weekend!!!

Darn it, in my quick attempt to make the code more readable, I forgot to rename one of the variables. Just rename ‘d’ to ‘data’ and the error will go away.

Step7 - I am at home now but I’m sure I did try replacing the d with data (in two places) and I’m sure I still had errors of some sort BUT please don’t put yourself out until I can confirm this, just thought I would mention it.

Colby - You said that the TCP driver would be tweaked to have an extra tag to indicate a fresh transmission has come in. May I ask when this will be available and will it be in the form of a new Ignition version (can I identify it through the log change document you publish?)

Thanks

I’m sure you made the changes, but you will find (and I can’t vouch how consistent this is) that changes you make to “while” loops in asynchronous calls do not take affect when running them from the designer. So, what you need to do is test the code in an actual running client (can be on the same machine), and restarting it after making changes in the designer.

I’ve been told it will be in the 7.2.6 release. You’ll definitely see it in the change log, under the TCP Driver (or maybe “internal drivers” section).

I would expect a new beta to be up early next week.

Regards,

Did the TCP driver get the change mentioned above as I don’t see it in the change log?

Sorry this slipped through the cracks. We’ll try and get in in there for 7.2.7.

Guys I had the same problem with capturing weights from a scale, but I was lucky that I passed the weight through a PLC, I wrote code so that if weight was the same I added a very small amount to make it different from the last.

hazey

Did this get done in 7.2.7 or 7.2.8?

I think that this may have been left out of the changelog which is my fault. There were 2 changes made to the tcp driver that made it into 7.2.7 :

1 - There is now a writable tag that allows you to write a string back to your tcp device
2 - There is now a tag (I believe with the name LastChange) that reports a timestamp representing last time that a value has been received. This timestamp is updated even if the value received is the same as the previous value.

Hope this helps.

I don’t see this new writable tag that you are talking about with the tag browser. I only see “Last Receive Time” and “Message”. I am running the latest version of Ignition (7.2.8.178) and I verified the TCP Driver module is 1.2.7.23.

You have to enable the writable tag as it’s disable by default. On the device configuration page on the gateway check the “Show advanced categories” option and then check the Writeback Enabled property. You can also specify a message delimiter if you device is expecting one.

Thank you. The strange thing was I thought I checked the advanced properties already and there was nothing there. Oh well, I can definitely see it there now. That should do what I need. I will try it out on Tuesday. Thank you.

This question may be more for Dave…or others who have used the new TCP driver. Our experience has been with direct connections between a PLC and a scale, but not PC to a scale. So, we decided to try the TCP driver in Ignition, but have not had much luck.
What we have is a Mettler Toledo scale that automatically spits out Net weight over ethernet. We tested it via Hyperterminal, and it works fine. But when we add the TCP driver in Ignition, and it says it’s connected, the tags stay red with a null value. We are using port 2305 (that’s the port that automatically feeds Net Weight on this particular scale). Is there something else that we are not doing? Any suggestions?
Thanks

The best place to look to start trouble shooting the problem is in the console any errors with connectivity will show up there. One of the changes that was made to the TCP driver is that the connected status now means that the driver is successfully started and is attempting to start listeners on the port(s) that you specified in device settings. I’m making some changes to make this more apparent and less confusing.

Check in the console and see if there are any errors being reported. There are two reasons that the tags will stay red:

  1. The driver hasn’t yet received any packets on the configured port or
  2. the socket connection isn’t successfully being made on the specified port

If a socket connection is failing to be made it will be reported in the console. If there are no errors then maybe there is something wrong with the driver configuration. If you still have trouble getting data to show up in your tags then give us a call here in support and I can take a look and see what’s going on.

Dave,
The TCP driver began working with the Msg. set to Packet Based, and Field Count set to 0. However, we do want to do some manipulation with the incoming string, so we were trying some other settings, like changing it to Character Based. When we did this and tried to save it, the localhost froze up. If we went back to the Gateway, the TCP driver was no longer there. So, we would reboot the PC or restart the Ignition server, at which time the driver would reappear, unchanged.
Do you have a whitepaper on the TCP driver, and formatting the incoming strings?
Thanks

I don’t have a whitepaper on hand that has the TCP setup information but the information that’s in the user manual about how to set up the UDP and TCP driver should still apply. The only thing that won’t be there is information on the write-back tag that was added.

First thing I would do however is download the newest version of the driver from the development section on the downloads page with 7.2.9-beta5 because that version contains a couple bug fixes that were made to address some issues when using character based message delimiters.

If you still have issues getting the device set up then please give me a call in tech support and I can help you through the set up process.