in reply to Controlling a non-perl GUI

Trying to attack the problem from a different direction:

What kind of interface does the microscope use to connect to the PC?

If it is serial (standard RS-232 or some bastardization of it), chances are that it uses simple ASCII commands to drive the microscope. You could capture and reverse-engineer those commands more easily than a proprietary binary file format.

Even if it is USB, those are sometimes realized with a serial-to-USB converter inside or outside the unit, and even if it is a proprietary USB-based protocol, you might have some chance of deciphering it.


Remote controlling a GUI that was not designed to be remote controlled seems like a really desperate last ditch effort to me (i.e. resort to this only if all else fails).

Replies are listed 'Best First'.
Re^2: Controlling a non-perl GUI
by dbae (Beadle) on Mar 29, 2010 at 16:01 UTC

    I'm taking what you and BrowserUK say very seriously, and I find what you say interesting and helpful, potentially saving me many days (weeks?) of wasted labour. My next step will be to install ProcessExplorer, as recommended by BrowserUK, and hope that what I find is comprehensible.

    I'm not sure that capturing the output from the computer to the robot will be that helpful. Maybe what the robot sends back is also important. It sounds foolhardy to try to control $300K worth of equipment without knowing what I'm doing. Even if I don't destroy the machine, I'm sure I would destroy the guarantee. So, if I can't get anywhere with ProcessExplorer, I will try what you call the last ditch approach, unless a better suggestion arises. Nevertheless, I find your lateral thinking very interesting and stimulating.

    Do your odds on my success with remote controlling the GUI improve when I report that the GUI screen covers the whole computer screen, so there is no chance of it moving or wobbling?

[reply]
      Do your odds on my success with remote controlling the GUI improve when I report that the GUI screen covers the whole computer screen, so there is no chance of it moving or wobbling?

      Does it ever pop-up dialogues whilst you are programming it? If you make mistakes?

      Are the menus contextual? Ie. Do the options available on the menubar, or within the dropdowns change at different points within the process of programming?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        Thanks everyone for your help. I am finally also getting a little help from the manufacturer. They have told me that the AssemblyRobot programs are put into a database that only MetaRobot can manipulate. I have also discovered that some of the manufacturer's own projects have been hampered by this poor decision. For example, it is not currently possible to pass a program developed on one machine to another, even though the machines may be identical. I'm going to go away now and will not add further to this correspondence unless I can do something interesting. Thanks again.
[reply]
      The point of not wanting to mess aroung with equipment worth $300k is a valid one, I can understand your sentiment.

      In that case, further questions: does this AssemblyRobot language have a clear text representation that is displayed in a box somewhere in the GUI? Does this box - or the program you call MetaRobot in general - accept text via copy/paste? I guess it doesn't or you would have had a solution already. But even if it doesn't, having such a text representation would make the situation easier, as you could assemble the necessary text sequences outside this horrid GUI and then feed it - keystroke by keystroke if needed - via some of the automation of GUI remote control methods mentioned earlier in the thread.

      I can't help but say that I find the attitude of your microscope vendor rather petty and close-minded. Instead of making their interface, file formats etc. versatile, open and well-documented thus more useful to the advanced user, they adamantly try to close off everything that does not conform to their "intended" modes of usage. Hiding so desperately behind the veil of closed source hints at ineptitude - that is their code is so horrible that they don't dare to show it to anyone.
[reply]
      I'm not sure that capturing the output from the computer to the robot will be that helpful

      Not necessarily. A colleague programmed two types of microscopes equipped with moving stages (Nikon and Mac2000), long time ago; both had more-or-less comprehensible command set. I'm not sure though if the set was grabbed through I/O dumping or he found manual somewhere (probably the latter), but f.ex. setting movement speed was as easy as sending "SPEED x=100\r" down the line.

[reply]

In Section Seekers of Perl Wisdom