Bytes at Port inconsistent, leads to faulty data

[rch5124]

johnsold,

i linked the error wires in to the match expressions functions. i dont think it'll really do anything because when the data messes up, the program will not stop, it will still run. and it will occasionally show the correct values but mess up more often than not from there on (again this is usually 6+ hours after running the program). i believe you are correct about the incorrect decoding as my string indicator shows that the data gets split up the wrong way after a while. The original software used to compile to program and collect the data pauses every 1 second (as it is set to collect every second) so I'll look into the frame delimiter and see if I can make any sense of that

Wayne C,

i don't have the PackBus protocal set up. But neither the computer running the program nor the micrologger are connected to any router or internet in anyway, so is that still relevant in this case?

[Wayne.C]

rch5124,

Manual for micrologger indicates that it communicates via PakBus, Modbus or DNP3 protocols over RS232.  Just curious because each protocol has unique characteristics that can be used to keep your communications synced up.

[rch5124]

RTSLVU,

I tried creating the additional you mentioned, but when I use the build array function and have it leave the loop via shift register,  I cannot connect it to the match regular expression function once I have it enter the main loop of the program. I'm assuming the broken wire is from the 2 functions being of different data types (array vs string) but I can't seem to get it. do you use a converter function to get around this?

[Jshu23]

I haven't used that device before, does it just keep spitting data over and over?  The devices I have used accept a command to query for information.  So my data collection functions by asking for data, waiting briefly, then reading the port to get what I asked for.

If your equipment just keeps spitting data, then I like an above suggestion about looking for the pauses.

Also, I notice your loop timing is 999 mS.  Is that time critical?  Maybe you could speed up the timing and adjust your data analysis and saving accordingly.

[Jshu23]

If you start with a string for your shift register, then the output will be a string.  Are you auto-indexing or something that is making an array instead?

Note: If you pull up the help window (ctrl-h) and highlight the wires it'll tell you the data type discrepancy.

[rch5124]

yes, it spits out the data. i dont think theres a command function. The program used to compile the raw data itself is call loggernet. so thats beyond my control. As for the loop timing, since the timer was set to 1000 ms because the data was to be displayed every second. the 999 ms that you saw was just a result of me messing around with the constant. But i dont think it'll work correctly with a large number. Say I make the wait time 5000 ms, then the data only updates/graphs/shows up every 5 seconds instead of 1 second

[smercurio_fc]

---

@rch5124 wrote:

RTSLVU,

I tried creating the additional you mentioned, but when I use the build array function and have it leave the loop via shift register,  I cannot connect it to the match regular expression function once I have it enter the main loop of the program. I'm assuming the broken wire is from the 2 functions being of different data types (array vs string) but I can't seem to get it. do you use a converter function to get around this?

---

That's because the function he's using is a Concatenate String function, not a Build array. An array wire is thicker. With the Context Help window open, hovering over a wire will display the datatype.

As I noted before, you cannot assume that the VISA Read will return to you a "decodable" string unless you've configured it to use termination character. Since you are not, your read will eventually get out of sync. It's inevitable. This is a code design problem. You must have a read loop like what RTSLVU shows that reads whatever is there. You look at the concatenate string to see if you have a full message, snip it out, and whatever characters are left over you send into the next loop. The read and processing should be kept as separate loops for maximum efficiency and rate control. Look at the master-slave or producer-consumer architectures.

Just out of curiosity, which micrologger are you using? Have you checked IDNET to see if there are any drivers already available?