Channel not displaying in graph

[CamEra]

Hi,

See the attached pdf which describes my issue.

Basically I have a series of channels

Sonde1_ch0

Sonde1_ch1 ...

to Sonde1_ch9

Channel Sonde1_ch0 won't plot.

Thanks

George

Graph issue.pdf

[AzeoTech]

There are four background colors on edit boxes in DAQFactory:

White means it isn't an expression
Red means it is an expression that either is invalid, or results in null (no valid values yet)
Green means it is a valid expression that evaluates to a number or array of numbers
Greyish means it is a valid expression that evaluates to a string or array of strings

So, that is your give-away.  For some reason, probably in your parsing routine of the incoming data stream, Sonde1_ch0 is ending up as a string not a number, and DAQFactory can't plot strings.

[CamEra]

Ahhh! I think this and my Parse problem are linked. If you look at that question I couldn't get the Parse command to separate out 4 items into an array with commas as separators so I did it using four Parse commands, one for each item which worked. I am wondering if that line of text from my instrument has some non printing character in the first few characters which means that it goes into the first item which should then be converted with strtodouble and being stored in Sonde1_ch0.

Time for a little more sleuthing.

BTW - Your colour coding of the background colours is another example of why I like DaqFactory so much - the programmers obviously thought long and hard about actions that would help us in the real world. That as well as the superb support we get.

Thanks

George

[AzeoTech]

Thanks for the kind words.

Try using the showhidden() function on your incoming string.  This will cause non-printing characters to show up in \ notation like the serial monitor.  

[CamEra]

Hmmm! you always have another function that I haven't thought about using. I did it by putting in a couple of system.messagebox commands, the first one displayed the value and the second displayed the the length of the string, they matched so no hidden characters. As well with your comment about the serial monitor, I have that open and watching the data come in and there are no hidden characters in the incoming string.

Back to the drawing board.

[AzeoTech]

Well, first, from a fresh DAQFactory start, try the two commands I did in the command / alert and see if you get the same thing I do (i.e. working parse()).  If you do, then you know the issue is specific to your data.  If not, then the issue is with parse().

[CamEra]

Did as you suggested without a fresh start and the Parse command is working fine so it is all to do with the data coming from the instrument, although that looks fine in the serial monitor

This is the input that is causing issues, looks good to me although there is one further step that I have to run which is to replace the "+" and "-" characters with either ""+," or "-," so that I can split them on the commas. Unfortunately the length of this line can change as it can change the number of decimals hence I cannot just use Mid to split the line. I'll go back to the two lines of code that add the commas to see if there is an issue there - but this code has worked for ages (like 5-6 years) without issue.

[AzeoTech]

That null character at the end may be throwing it.  Are you doing readuntil(10)?  If so, then you may be picking up the \000 from the previous request as the first character of the new response.  This is why for query/response protocols I always do purge() before I send the query.  That ensures no lingering bytes are in the buffer.  \000 is an unusual character as it is used a terminated in c-style strings.  DAQFactory doesn't use c-style strings, but some of the core C functions we use take them and so our strings are temporarily converted to c type strings.  In these cases, that \000 can really throw things.

My guess is that you didn't get \000 before and that is something new.  It probably isn't real as throwing an extra \000 after a CR/LF would be quite atypical.  My first thought would be that you have some noise in the line causing an extra character, possibly during some sort of electrical transition in transmission, something you sometimes see in RS485.