Phillip Brooks Posted July 19, 2011 Report Share Posted July 19, 2011 I'm looking at two devices that I need to interface with from LabVIEW that have no command line control. They both use a interface that is RS232 based. The menus require a VT-100 terminal type and use a fair amount of cursoring (goto x-y and write text with this color and bkgrnd color) and highlighting to show the current location. I have some legacy code that I don't care for much that polls the com port and strips all the VT-100 control codes out. It works, but the device doesn't respond 100% of the time to control codes (send arrow up or arrow down). If the LabVIEW com library I'm using gets stuck or lost, it has to navigate back to a known position and then navigate the menus again to ensure that the instruction given is correct. Sort of a dead reckoning problem; sometimes its easier to reset the device than to figure out the current location in the menu hierarchy. I can just suffer with this library, but I would like to automate some new tests. If there is an existing LabVIEW library, architecture or technique I can use, I would likely pick that over this existing steaming library of... Anybody? Quote Link to comment
crelf Posted July 19, 2011 Report Share Posted July 19, 2011 Can't imagine you're going to find anything - if your device is flaky at times, then dead reckoning might be your best bet. You can make it more robust by dead roeckoning way back to the base menu (or whatever it is) but knowing the depth of the deepest menu you ever enter (or that exists < safer) and escaping (or whatever) that many times to the base menu, and then renavigating back in from there. Horrible, yes, robust, mostly. Unless you can tell us what the instrument(s) are that you're looking at, that's about all I think I can offer. Quote Link to comment
Phillip Brooks Posted July 20, 2011 Author Report Share Posted July 20, 2011 Can't imagine you're going to find anything - if your device is flaky at times, then dead reckoning might be your best bet. You can make it more robust by dead roeckoning way back to the base menu (or whatever it is) but knowing the depth of the deepest menu you ever enter (or that exists < safer) and escaping (or whatever) that many times to the base menu, and then renavigating back in from there. Horrible, yes, robust, mostly. Unless you can tell us what the instrument(s) are that you're looking at, that's about all I think I can offer. I think the device responding properly is a function of sending navigation keystrokes while the device is updating the output. Like I said, the LV library is dodgy at best. As for the device, it is ours, it is old and the chances of getting a CLI are < zero. I might spend some time thinking about a LVOOP solution (still haven't deployed any LVOOP, just experimenting), but it is summer time and the weather is too nice to worry about such things... Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.