LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Extech MP530 - Newbie attempts

Hello,

 


Newbie is struggling looking for pointers.


Reference the following link for MP530 protocol information and examples of serial communications that are occurring:

http://forums.ni.com/ni/board/message?board.id=140&message.id=25628

 

 

Attached:

A) my current application revision 20070912

B) Portmon outputs (Viewing HEX) from my current apps start, run, and closure.

 

Questions:

  1. I am having a heck of a time correctly pulling data out of the hex string using some of the methods that I seen within the discussion forums: 2 types that I am having problems with are the “string to byte array” and the “type cast”, so much so that I gave up trying.  If anyone has some actual examples that I could use I would be grateful.

  2. I am able to pull data by filtering the string subset...why is the string output(at location "first multimeter string")  not in hex format but ASCII?

  3. When using the application attached, the output of the DMM varies between the reading taken and 0.  So basically the output is toggling.  Any ideas on how to prevent this?

 

 

Thank you for your time.

jqm

Download All
0 Kudos
Message 1 of 6
(3,237 Views)
bump
0 Kudos
Message 2 of 6
(3,129 Views)
I did a scan through the spy file and looked at the data read and looked at the instrument manual and I think the attached modification will work. You were only getting 6 bytes and you need to get 11 in order to get the exponent. Then the spaces need to be removed in order to convert to a dbl.
0 Kudos
Message 3 of 6
(3,110 Views)

Dennis,

 


Thank you for your response and the time you took to post a suggestion. 

I just tried the file and unfortunately the output still toggles between a multimeter reading…. And “0”.

Just like the bytes read toggles from 22 to zero, with the read meter HEX string toggling from a ascii string to blank

 

I have attached a new Portman file

Any ideas on how to stop the output from toggling?

 

Thanks

jqm

0 Kudos
Message 4 of 6
(3,101 Views)
jqm,

I see a few things which may be relevant.

1. The Com port initialization does not do what the protocol calls for. Run the VI with execution highlighting (the lightbulb button on the diagram window) on to see this. The sequence structure above the RTS State property node will execute completely before the property node executes at all. So you will get RTS=1, RTS=0, RTS=1 as fast as the system can execute, starting after the sequence structure has completed not ate 100 ms intervals. And the sequence structure may start executing before the Serial Init and VISA Open are complete as there is no data dependency.
2. The Command Protocol document refers to a "Wait 1 ms or less" (without specifying how much less), but you have no delays between bytes. Maybe "less" is enough. The data could be put into an array and then put the VISA Write (and 1 ms delay, if needed) into a for loop.
3. You have the serial port configured for XON/XOFF handshaking. The Com protocol does not mention flow control. If your data includes an XON or XOFF character, this could produce unexpected results.
4. The data you linked do not specify how fast the instrument can generate readings. If you are requesting new data before the instrument has had time to take the next reading, does it return zeros? Your loop has a 4 ms delay (Interval for Readings) which will expire long before the 500 ms delay before read so it does nothing.
5. You can flush both buffers simultaneously by combining the masks. Look at the detailed help for the Flush function.

Lynn
0 Kudos
Message 5 of 6
(3,092 Views)

You could place a case statement around the VISA Read and the conversion code. If byte count is greater than zero, do the read and conversion. I'm not sure why there would be zero bytes at times. Could it be that the meter is just not capable of whatever speed you are running at?

You could also take out the two VISA Flush Buffer functions at the beginning. As long as you read all of the bytes, you should not need to keep flushing. Since it appears that the instrument always sends 22 bytes, you could alos try removing the VISA Bytes At Serial Port and using a fixed byte count for the VISA Read. If the instrument is being read too fast though and sometimes doesn't return a value, this would not be a very good idea.

0 Kudos
Message 6 of 6
(3,086 Views)