Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
How to use the new Serial Data Source in Mango Automation 2.1
-
Can you ensure that the message being received by Mango is terminated by \r
Mango will not start parsing the message until it receives the terminator character.
-
It looks to me like the configuration is a bit off...
On the data source,
-
Point identifier index 0 means regular expression match index 0, which will be your entire match (specified match groups start at 1). So, if your response is 100 characters that whole 100 characters would need to be the Point Identifier of the receiving point. So, for testing, let's capture an easy point identifier,
Data Source Settings:
'Message Terminator' - \r
'Message Regex' - (~).*\r
'Point Identifier Index' - 1 -
The Point Identifier must match the capture through exact comparison, not regex. So,
Receiving Point
'Data Type' - Alphanumeric
'Point Identifier' - ~
'Value Index' - 1
'Value Regex' - ~(.*)\r
-
-
hi Phil. We tried as your instruction but failed to received anything. But the return message can be monitored by a monitoring tool on the same machine.
I did that successfully before in Mango 2.1 by replaced the original log4j with a new one which you gave me.
I know that was disturbed but it can work. Could you please help us out again? We are in late deployment phase of a real customer case.
BTW, Marc is my colleague. Thanks.
-
I think that's a yes, Terry.
I should have posted the log of COM monitoring tool. It shows clearly that mango receives the message which terminated by \r.
Since Philips've given a set of new configurations, it's better that I offer you new logs. Will do that as soon as I get those logs.@terrypacker said:
Can you ensure that the message being received by Mango is terminated by \r
Mango will not start parsing the message until it receives the terminator character.
-
Hi,Philips. We followed your instruction but Mango showed no value of the receiving point.
The attachment is the log from COM monitoring tool, as same as last time with my configuration.
Both sending and receiving messages can be seen. The "java.exe" means those are from and to the Mango thread. The suffix "." is the printable form of "\r", as the hexadecimal form of the message shows that's a "0D" charactor.I've also set ```
<category name="com.infiniteautomation"><level value="all"/></category>Could you guys have a look and find what's wrong there? @phildunlap said: > It looks to me like the configuration is a bit off... > >On the data source, >1. Point identifier index 0 means regular expression match index 0, which will be your entire match (specified match groups start at 1). So, if your response is 100 characters that whole 100 characters would need to be the Point Identifier of the receiving point. So, for testing, let's capture an easy point identifier, >Data Source Settings: >'Message Terminator' - \r >'Message Regex' - (~).*\r >'Point Identifier Index' - 1 > >2. The Point Identifier must match the capture through exact comparison, not regex. So, >Receiving Point >'Data Type' - Alphanumeric >'Point Identifier' - ~ >'Value Index' - 1 >'Value Regex' - ~(.*)\r Attachment: [download link](http://archive.infiniteautomation.com/forum/posts/downloadAttach/276.page) -
Okay, let's be sure of things like what version you're using. On the modules page, what's your core version? What's the version of the serial module? In your mango/lib folder, do you have A. RXTX jar file B. JSSC jar file?
As far as further tests, let's change your message terminator in all relevant spots to '2', point identifier to '1' and see if it is getting values then.
-
Hello, Philips.
There are two machines: a working machine with mango core 2.2.2, serial 1.1.0, and with commercial mango license; the other is a notebook for testing, with the same version of mango but a free license.
In the lib folder, no rxtx jar file, but a jssc-2.8.0.jar. I assume that's what it should be.The test results were confusing, but some things came out, I'll describe that in the next post.
@phildunlap said:
Okay, let's be sure of things like what version you're using. On the modules page, what's your core version? What's the version of the serial module? In your mango/lib folder, do you have A. RXTX jar file B. JSSC jar file?
As far as further tests, let's change your message terminator in all relevant spots to '2', point identifier to '1' and see if it is getting values then.
-
The tests on the working machine got nothing as before.
But with the same configuration running on the testing notebook, it succeeded at the first time, as the receiving point had a value of "1001". Unfortunately, on every try after that we got only an event instead.In the test, we changed the message terminator to '2'. That made the sending message become "~10012A410000FDA62".
And the response changed to "~10012A050000FDA6", which was actually a message telling us the sending message was malformatted. But it was good for the test.At the first time, we got a match, "1001", from the response, which became the point value. We could not tell if there was an event at that time.
After that, we got no point values, but events saying "Recieved message: (~).*2 does not match pattern: A050000FDA6 ~10012".
It seems the places of the received message and the pattern were switched in the event message.The serial port monitoring logs, screenshots of data source/points configuration and events are archived and attached. Please let us know if there's anything wrong. Thanks.
@Marc said:Hello, Philips.
There are two machines: a working machine with mango core 2.2.2, serial 1.1.0, and with commercial mango license; the other is a notebook for testing, with the same version of mango but a free license.
In the lib folder, no rxtx jar file, but a jssc-2.8.0.jar. I assume that's what it should be.The test results were confusing, but some things came out, I'll describe that in the next post.
@phildunlap said:
Okay, let's be sure of things like what version you're using. On the modules page, what's your core version? What's the version of the serial module? In your mango/lib folder, do you have A. RXTX jar file B. JSSC jar file?As far as further tests, let's change your message terminator in all relevant spots to '2', point identifier to '1' and see if it is getting values then.
Attachment: download link
-
I'm not surprised. Unconsumed characters are lingering in the serial stream, and it isn't configured to discard anything. This is causing it to gunk up, but it's getting one value so we can be sure now that Mango is getting the data we're expecting...
Which means the \r terminator character is likely incorrect on one of our ends... Ah, it appears we needed to unescape our terminator field in the code... Give this version a shot:
Edit: Switched versions on ya... give this one a shot
Attachment: download link
-
Hi, Philips. Is there anything we should take notice of when using serial-1.1.2 ?
When we tried to add a serial data source, there was a verification failure on the "message terminator" field. We inputted \r , yet it acted like there was no input value.@phildunlap said:
I'm not surprised. Unconsumed characters are lingering in the serial stream, and it isn't configured to discard anything. This is causing it to gunk up, but it's getting one value so we can be sure now that Mango is getting the data we're expecting...
Which means the \r terminator character is likely incorrect on one of our ends... Ah, it appears we needed to unescape our terminator field in the code... Give this version a shot:
Edit: Switched versions on ya... give this one a shot
Attachment: download link
-
My bad... fixed that, hopefully this one works for ya.
Attachment: download link
-
It worked. Thanks, Philips.
Now we have to work on the issue of multiple response messages from the same serial port.
Let's say there're two sets of messages:- If we send the command "~10012A410000FDA6\r" , the response will be "~10012A00xxxxxx\r" .
- If we send the command "~10012AE100003D9E\r" , the response will be "~10012A00xxxxxx\r" .
We are trying meta data points to make automatic and periodic sending.
One sending point can be used for two commands, but both responses will appear in the same receiving point.
How can we differentiate them, or how can we connect one response to its command?
@phildunlap said:My bad... fixed that, hopefully this one works for ya.
-
When setting a particular point, the message sent is pointIndentifier + [setValue] + messageTerminator
When differentiating points, you need a more subtle capture group in the datasource regex for the pointIdentifier to match the point's identifiers individually.
Sometimes the best tactic for a protocol is to set all points individually, but sometimes the better tactic is to have a single command point to send all commands through and use other points to receive values.
-
Thanks, Philps. One sending point or multiple sending points, these ways are both good.
Since response messages have the same format, how can we tell which is the response to command 1, which is to command 2?
@Marc said:
It worked. Thanks, Philips.
Now we have to work on the issue of multiple response messages from the same serial port.
Let's say there're two sets of messages:- If we send the command "~10012A410000FDA6\r" , the response will be "~10012A00xxxxxx\r" .
- If we send the command "~10012AE100003D9E\r" , the response will be "~10012A00xxxxxx\r" .
We are trying meta data points to make automatic and periodic sending.
One sending point can be used for two commands, but both responses will appear in the same receiving point.
How can we differentiate them, or how can we connect one response to its command?
@phildunlap said:
My bad... fixed that, hopefully this one works for ya. -
So, in theory, if you sent both messages, the protocol is ambiguous as to which response refers to which question?
The only way I can see that working is using two meta points to buffer the commands and responses for sorting by a script to the appropriate endpoints. Then the serial datasource may have very simple points that catch everything, the meta points addend whatever new message is coming or going, and the script processes the message queues into its own points. You could also write a module for this protocol that hides/accelerates the analysis portion.
It may help to know the serial data source is open source: https://github.com/infiniteautomation/ma-modules-public/tree/master/Serial Data Source
-
Managed that using scripting data source and meta data source.
Thanks again for all the help, Phil. -
Glad it worked :D
Thanks for bringing the escape character issue to our attention!
-
Hi, Philips. Didn't expect to come back so soon myself :)
We start working on a new device with mango 2.4, and I have to use \r\r\n as the message terminator.
Turns out serial data source doesn't accept strings more than one character as the input.
I've checked with the source codes from where you gave, and found that message terminator was of a java.lang.String type.
So is there any chance we get serial data source into accepting characters, other than one character, for the message terminator? -
Hi Marc,
It looks like that restriction was improper. I removed it and tried to read around to validate it, but my serial cables have seemingly grown legs and I can't test as thoroughly as I'd like. Let me know!
Attachment: download link
-
Thanks, Philips. I've tested this version.
First of all, I was wrong about the protocol. It's a "20H 20H 0DH" at the end of the message, not a "0DH 0DH 0AH" as I thought before.
So I tried "\s\s\r" at first, and something about escape was wrong. On saving data source properties, this version lost the first two \ charactors and turned "\s\s\r" into "ss\r". You may want to look into that."[space][space]\r" seems not so well-formed to me, yet it got a correct command message to send.
Then again, the protocol, which is definitely not my favourite, has this response like "0DH 41H xxxxxxx 20H 20H 0DH xxxxxxx 20H 20H 0DH xxxxxxx 20H 20H 0DH"."20H 20H 0DH" is the end of response, but it also shows up in the middle, twice. Is it still OK to use it as the message terminator?
@phildunlap said:Hi Marc,
It looks like that restriction was improper. I removed it and tried to read around to validate it, but my serial cables have seemingly grown legs and I can't test as thoroughly as I'd like. Let me know!
