replacing null with zero, really can't figure it out

[nadda]

so i have a device which i am collecting measurements from. it is connected to a port (through rs232).

i have a main while loop which is collecting info. and i have a sequential case structure outside the main function which is the process which it goes through to actually collect data. i store info from a DAQ and from the serial port into a file. however, when i open the text file and look at the data, under the column for the serial port info, sometimes i get 0s. the thing is that these zeros are supposed to be null values. i am guessing that the while loop is just going too fast and can receive info from teh DAQ device at a faster rate than what the serial port instruction in the outside case structure can do. 

is there any way where i can get the info from the serial port and get the info from the DAQ (which is within the while loop) at the same rate. my main problem is that in my measurement file which collects both info i am getting 0s for the values of the info from the device attached to the serial port, which are acutally null values but these null values screw up the overall file.

[LV_Pro]

I'm not sure exactly how your program works, but am going to assume that the sequence structure is to set up some serial port based instrument to begin capturing data? As a point of fact, as LabVIEW is a data flow language the sequence structure is redundant as all of the serial setups, writes and reads are wired together by the Visa resource wire, each element will not execute until it is passed this from the proceeding. Now, with your loop running at some multiple of 1 sec you maybe reading a null if the serial port hasn't gotten any data on this particular loop, particularly if your slider is set to zero, which would be a zero time loop. There is also the possibility that with the first reads being performed in the "sequence" and with no delay between that and the beginning of your DAQ read, you may have read the serial instrument before getting into the loop.

[mrj]

i don't know wat you mean by my slider being set to 0. as for the sequence, i have watched the slowed down version of the program running and have seen that the serial port is hte first thing executed within the program. it is only after the case sequence is done does the value go intohewhile loop and then the while loop execution starts.

[LV_Pro]

The slider I'm refering to is the one attached, in the loop, to the multiplier times 1000 before the timer that determines the minimum loop execution time. Set to zero it would mean that the loop executes as fast as the DAQ/ file writes can happen, possibly meaning that when you read the serial port again nothing has been updates. As to watching the program execute in debug mode, yes the serial port "stuff" in the sequence structure will execute first, as I stated LabVIEW is a data flow language and you have the "visa resource reference" wired from the last serial read in the sequence into the loop. Being a "data flow" language means that the loop doesn't begin executing until all of its "inputs" which that wire is (as well as the user dialog picking the file name) are supplied. As I mentioned, you could remove the sequence structure in this program and it would execute identically as all the serial read/writes are wired "in series" with the visa resource wire. Now watching the program execute in the debug mode does not mean that the data will be present by the time you enter the loop, at least not in a "normally running" mode. Debug obviously slows everything down by orders of magnitude, so if the serial device takes time to configure itself before the first reading it won't show up as a problem when you run it super slow in debug, but might not be in the right state when you run it at the full speed. If the unit needs time to configure itself and make a reading, then it is possible that there wouldn't be enough time.

Does the unit output continous readings? In the sequence structure part you send it commands, not sure whether these tell it to output continuous readings or not. If it does, how often does it update? As mentioned above, if you try to read it between its outputting its next reading, quite possible if looping very fast, you will get a null out of the serial read, which will be a zero after the conversion. Many (most?) serial devices that make and supply readings need a query to initiate a reply, and the reply, while fast, is not instantaneous.

[nadda]

good point about not needing the case sequence structure. if i take it out, it should still work the same.  now i am considering taking that sequence all togehter and putting it inside the main while loop. trying to figure out whether the program will still run as desired?

have you ever used the VISA read or VISA write functions? if you have or you know how they are used, do you know why the "bytes to port" part always have to go into the VISA read function?

my second question would be why stuff ;like iB, 0D1B, or 6720 320D are placed into the write function. i talked with someone and they said that those are just ASCII HEX forms for keys with each key being entered as some command to perform on the decvice which is connected tot eh serial port. 

[LV_Pro]

I guess the first question that needs to be asked is do you know how the serial port instrument works? Do you have a user manual, programming manual, something of that sort? I would guess that the initial "stuff" that iare sent to the visa writes are commands to set up the instrument to make a reading. I have no clue what they are though. Many/most instruments require a command/response type of behavior, something like a command that says "what is the measured voltage at input A" (in a much simpler format i.e. "VoltA?") and what is read back from the instrument would be its response, frequently a formatted string ("3.25V"). The variation on what command is sent and what is received is almost infinite, with some manufacturers following industry standards, others making up their own protocols. The stuff you send is a combination of Hex strings (non-printable characters) and a ASCII string, which is probably the "command". If you put your cursor over the "string constants" being fed to the visa writes and right click, the drop down will show Normal display, '\' Codes Display, Password display, Hex Display. These are the various ways to look at the string values. the \ codes are a way to display "spaces" (\s), carriage returns(\r) and other control characters. The password display replaces all the characters with **** 's, and the Hex display shows the hexidecimal numeric value of the string character, which for some uses will not be a normally displayable character.

In a VISA read, the number of bytes has to be supplied for it to "know" how many bytes to read.