LabVIEW
Error: "BFFF0015 Timeout expired before operation completed."
Hi Dr Berns
LabVIEW can send on the serial port what other software can, and I guess that a service for this microscope is blocking the port.
In fact no other software should be necessary except a good driver (in LabVIEW of course)
Indeed microscope manufacturers are not the best software guru's around
Almost as bad as weighing devices are handled
LabVIEW can send on the serial port what other software can, and I guess that a service for this microscope is blocking the port.
In fact no other software should be necessary except a good driver (in LabVIEW of course)
Indeed microscope manufacturers are not the best software guru's around
Almost as bad as weighing devices are handled
@Dr.Berns wrote:
Hello Ben, the question is the exactly the subject in my message header here (loading...). Yes, sir I did that too and it has the same effect it forces the whole thing to go offline? So, I investigated various PC or notebook port schematics of RS232 and went through again in the details of RS232C protocol even did an In-Circuit which I saw a lot of things going on at the start-up and as well as the port levels when it is on-line? I'm almost ready to use the lab's logic analyzer for it and adapt another approach aside from sniffing them. I also looked at the possibility of using a serial protocol analyzer if I can find one? What can a programmer or hardware guy did so that it's not possible to sniff it or use NI Spy on it, load it when when another monitoring port is connected to it or disable the sniffer at run time?
What do you think?
Regards,
Berns B.
Are you saying that starting up http://www.sysinternals.com/ntw2k/freeware/portmon.shtml after the Olympus software has connected will terminate the connection? This would seem like active anti-hacking techniques in the software!
Also connecting a passive, meaning listening only on both lines (A PC alonce can't really be programmed to do that with only one serial port so that you would need two ports with a special cable), external monitor will disconnect, too?
Last but not least NI Spy only hooks into the NI-VISA calls. It is unlikely that non-NI software uses NI-VISA to talk to the serial device, so NI Spy will not see the traffic going directly through the native Windows Comm API. On the other hand NI-VISA does sit on top of the Windows Comm API to talk to serial devices, so the sysinternals Portmon program will also see that traffic as it hooks directly into the serial port kernel device driver through its own filter device driver. A normal application including NI-VISA should not be aware of its existence at all, unless it takes a conscious effort to check for that.
Another small chance is that the portmon device driver adds some small delay to the passing of IOCTL calls to the actual device driver so that the timing of serial port messages is slightly changed. If the combination of Olympus software and microscope however would rely on such a tight and exact timing on the serial port the only way to achieve this would be by implementing their own kernel mode device driver. Which would be another possible reason why it might not work. The portmon application hooks to the serial port kernel device driver and a possible Olympus kernel device driver would need to do the same. So one might be capturing the hook from the other one, in effect breaking the hook chain. That however would be a very strange way of doing business with a serial device from a Windows application. Developing a kernel device driver is VERY complicated and aside from being a somewhat good anti- sniffing technique has little advantages. A software developer choosing to write his own kernel device driver for serial communication applications is almost mad in his mind or extremely paranoid, which is basically the same.
Rolf Kalbermatter
The messages look not that complicated at all.
Your computer sends a command "2POS?\r\n" (without quotes and for the backslashes you should enable the / Codes in the popup menu of the string control).
I would assume the number 2 is the axis, POS is the command and the question mark is an indication that this is a query. \r\n is the end of string indicator and really is a carraige return + line feed.
The device then sends back an answer "2POS\s484\r\n" which is quite obvious except the actual coordinate translation but some experimenting will show that too. I would assume that by sending "2POS\s484\r\n" on could probably cause the axis to move to that position too.
From what I can see, this seems like a quite simple and not to badly thought out communication protocol and so should work quite easily, when making sure that you send the carriage return/line feed characters at the end of each command.
Rolf Kalbermatter
Your computer sends a command "2POS?\r\n" (without quotes and for the backslashes you should enable the / Codes in the popup menu of the string control).
I would assume the number 2 is the axis, POS is the command and the question mark is an indication that this is a query. \r\n is the end of string indicator and really is a carraige return + line feed.
The device then sends back an answer "2POS\s484\r\n" which is quite obvious except the actual coordinate translation but some experimenting will show that too. I would assume that by sending "2POS\s484\r\n" on could probably cause the axis to move to that position too.
From what I can see, this seems like a quite simple and not to badly thought out communication protocol and so should work quite easily, when making sure that you send the carriage return/line feed characters at the end of each command.
Rolf Kalbermatter
