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.
Mango V4.4.2 Serial Data Source Escaping CR LF Characters Wrong?
-
@Turbo I found a bug with the serial data source combined with the virtual serial socket meant that after a reboot, you had to save the serial data source in order for it to restart and properly fire up the virtual serial socket.
I wonder if you're encountering a similar issue here....Fox
-
@MattFox Indeed. I couldn't use the Serial Data source via Mango V4, because of this issue: I'd suggest maybe adding this to V4- A data source that can't auto-start isn't particularly reliable. I had to switch to using the TCP data source for my solution, and using an Ethernet to GPIB Adapter to parse the SCPI stuff to get the Source meter working.
It's working now, but the fact I had to use another set of adapters due to bugs in the Mango V4 serial data source is nonideal for this.
-
@Turbo if you're using linux, you can use socat to do a serial to tcp connection instead.
Fox
-
@MattFox For other folks who come to this thread, I was able to use the Prologix GPIB Ethernet Adapter: https://prologix.biz/product/gpib-ethernet-controller/
I have a working set of Mango Configs that I've got working to talk SCPI using the GPIB <-> Ethernet device servers to make this work. I originally tried to get this working with the Serial data source, but ran into a host of issues related to this.
Mango's quite versatile, but apparently the Serial data source chokes on SCPI-style commands- One reason was noted by @MattFox earlier in the thread, but it's also part of a problem with SCPI: Mango expects all data sources to return data, and some (many) SCPI commands don't actually generate an acknowledgement.
The GPIB <-> Ethernet adapter has the same problem, but the timeouts are faster, and you can use a trick in the Prologix device (++auto 1) to basically stream data into mango in Real Time.
The Mango config I put together for this is quite large, but if you're looking for SCPI interfacing, I'd imagine this script would work well for Native Ethernet as well as Vintage GPIB devices using an Etherent <-> GPIB device.
The Prologix one I linked above is the more affordable of the choices- you can just telnet into it, and issue commands, and it spits stuff back. It's actually quite cool.
-
@CraigWeb this one needs to be fixed for both 3.7 and mango4
-
@MattFox
@Turbo
ill be honest im a little out of my depth when it comes to raw serial and tcp communication.could we maybe summarize this thread, this is what I'm seeing:
- serial data sources don't restart after a reboot
Was this tested pre v4.35 as there were a number of serial fixes in 4.3.5
*When serial points are set, the string value of the terminator is used and not the escaped value?(help me here)
- Wiki pages are not available.
Unfortunately, the wiki pages were a project by previous employees who left the company and no one has any records of those pages. I don't see us recovering them.
- serial data sources don't restart after a reboot
-
@CraigWeb said in Mango V4.4.2 Serial Data Source Escaping CR LF Characters Wrong?:
Was this tested pre v4.35 as there were a number of serial fixes in 4.3.5
Yes it's an issue in 3.7, just start mango with a serial adaptor and nothing will read or write without restarting the datasource.
When serial points are set, the string value of the terminator is used and not the escaped value?(help me here)
The UI escapes the control characters used so a single ASCII character becomes two individual characters. This means end of line terminators cannot be used to terminate a string/serial feed ie \n for new line becomes one \ and one n
-
@MattFox Heya: Just for clarity on this: I was able to get this to work using the suggestion you had: The UI escapes control characters, but if you export the points in JSON, and change it to \r\n (or \n\r or whatever) and re-import, the serial data source will work. You just can't see the control characters in the data source, which could cause confusion if people go back later to fix it.
-
@Turbo yeah, I want radix to have an option to set ctrl character delimeters with a symbol or something so it is effectively parsed as desired under the hood.
I don't want an option to set between them and custom because people may need a combination of the two.Fox
-
So our current policy is that we will only fix security issues on v3. @Turbo I will create an internal ticket for the UI bug. Could you help me describe it better and what the acceptance criteria for the fix woulds be ? sounds like it is just a front-end form bug if you are able to work around it via the json import
-
@CraigWeb Sure:
This is running the latest Mango V4.5. I'm using the Raw TCP data source to chat with a TCP <-> GPIB Adapter, but this bug (also) appears in the serial data source as well. It mentions it in the documentaiton somehwere, too, that you should be able to put \r\n in the "delimiter" and have it sense that as the end of message.
This does not work.
To make it work, you have to download the JSON file and manually put in "\r\n" and then re-import it, at which point the datasource "delimiter" blank shows up blank.
Here's the screen grab of our (working) data source:
Notice: Nothing in the "Delimiter" field.
If I download the JSON for that data source, however, I see this:
"updatePeriodType":"SECONDS", "delimiter":"\r\n", "hex":false,which shows the proper delimiter. This works (btw) so mango is processing the delimiter properly internally, it just doesn't display right in the UI.
"acceptance criteria" would be "The actual delimiter value should be visible in the Delimiter blank, somehow, even of it consists of nonprintable characters"
In the datasource help, attached below as a screen grab, with my highlighting shown, it says " Delimiters are unescaped before sending, so "\r" translates to carrriage return.":
If you put "\n" in that blank, you get this in the JSON:
"updatePeriodType":"MINUTES", "delimiter":"\"\\n\"", "hex":false,If you put \n (no quotes) you get this:
"updatePeriodType":"MINUTES", "delimiter":"\\n", "hex":false,Which seems to mean that the parser expects \\n (not a \n)
The only way I was able to get the TCP data source to store the data using \r\n was to edit the JSON file as above, which seems to work properly. But then the \r\n doesn't show up properly in the "delimiter" blank
