Re^2: Controlling a non-perl GUI

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?

Comment on Re^2: Controlling a non-perl GUI

Replies are listed 'Best First'.
Re^3: Controlling a non-perl GUI by BrowserUk (Patriarch) on Mar 29, 2010 at 16:08 UTC
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. "I'd rather go naked than blow up my ass"	[reply]
Re^4: Controlling a non-perl GUI by dbae (Beadle) on Mar 31, 2010 at 16:29 UTC
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]
Re^5: Controlling a non-perl GUI by BrowserUk (Patriarch) on Mar 31, 2010 at 17:25 UTC
I have also discovered that some of the manufacturer's own projects have been hampered by this poor decision. Tell'em that if they'll donate the hardware, I'll fix their problem for them :) 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. "I'd rather go naked than blow up my ass"	[reply]
Re^3: Controlling a non-perl GUI by kikuchiyo (Hermit) on Mar 29, 2010 at 20:30 UTC
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]
Re^3: Controlling a non-perl GUI by dk (Chaplain) on Mar 30, 2010 at 08:44 UTC
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]