As a technician, I am currently working with a variety of hardware that ranges from current issue, to 30+ year old legacy devices, and I have been working to modernize the desktop computers that manage much of the test equipment (in order to reintroduce them to the local network for data security purposes).
Many of the systems are running Windows XP, and are unsafe to put on the network, but the software that they are running is essential to perform many of the tests we are responsible for.
Some of the required software was built in-house, and has been proven to work on Windows 10, but depends on the SICL protocols provided by Agilent/Keysight IO libraries to communicate with the test equipment connected to the PC. The physical connection is made using a 82357A or 82357B USB-GPIB converters.
What I am finding, is that old versions of Agilent Libraries (15.1) will recognize my California Instruments CI5001I power supply but the latest (2019) version of Keysight Libraries will not. In the old versions, it shows the model, serial, and revision data in Connection Expert. In the new versions, everything is unknown. I CAN, however, open the interactive IO platform and get a response to the *IDN? command (as well as other device specific commands) on Win 10, so I know that the device is communicating to some extent. In fact, the software I am using is almost entirely dependent on those SCPI commands, which I can enter manually, but cannot send via software due to addressing problems with SICL.
Can anyone explain what might have changed? Are there any workarounds available? I have been told that the California Instruments IO interface was potentially designed by/purchased from Agilent, which seems to support the notion that the two should be able to communicate. I realize this is not a Keysight device, but seeing as I have a functional example in Windows XP that works, I hope someone might have some insight on how device discovery or addressing might have changed just enough to make older programs unable to use them.
I also had similar problems relating to the SICL protocol/addressing/communication when trying to address my Agilent 34970A Data Acquisition Modules. Specifically, any of the programs using the sicl32.dll (programs which work on older versions of Windows) no longer work when ported to Windows 10.
I have managed a work around with the 34970A by applying fixed addresses on the software side, but it isn't a stable long term solution, but a workaround. That solution does not appear to work for the power supply though. Interactive IO show a VISA address for the device, and Connection Expert shows that it has also been given a VISA and SICL address, but commands like iopen fail or time out (can't tell which).
I know the original executables of these programs were built in a variant of Object Pascal, and have reference libraries that port/translate the data from the C version of sicl32.dll, but I do not have complete versions of the source code to reference. What I am hoping to learn is what changes might have been made between versions, and what directions I can look as I continue trying to port these applications into Windows 10.
Any help or suggestions would be very much appreciated!
Update:
I have successfully managed to make progress on this project, though there are still some bugs to work out to completely stabilize the system.
One of the major issues I was running into on the communication side was command speed. Software that ran well on the older generation of PC hardware is executing commands much faster on a (multi-core) modern Windows 10 build, but the devices themselves have not changed. This was creating both read and write errors when trying to move data in and out of the buffer. Throttling on the software ("driver") side has stabilized a number of pieces of equipment, enough to allow my test software to communicate with them (at least). Things like wait or sleep times (measured in ms or ns) in programs like these, aren't actually synced to a real time clock but use the system / bus clock, so their behavior is more variable than an RTC would be.
Additionally, it appears that (weather called / configured or not) the new SICL error handler will react to errors that it encounters. The test software and "drivers" have no calls to the error handler that I could locate, and the software was blocking popup windows (and thus I could not actually see the error messages) but using the built in IO Monitoring, I saw that it was reporting errors.
With some mucking about with Windows software diagnostic tools, I managed to find something that interrupted the test software before it could block the popup windows. To be honest it was a shotgun "throw a bunch of things at it, all at once, and see what sticks" approach, as I was getting a little frustrated, so I'm honestly not sure what tool it was that actually worked. That lead to some more code diagnostics on the "driver" side, which was creating conflicts with the status bit.
One of the issues that is still troubling me is device discovery. Due to the need for using the test equipment for actual testing, I was moved to a different PC for some of this diagnostic process. In order to work on this project, I needed to install the latest version of IO Libraries on the new system (exact same download that I used on the original PC. Same files, same flash drive). That system was essentially a new clean build of the same version of Windows 10, just different hardware. Using the exact same 82357A USB-GPIB converter, the system was able to recognize the CI5001i Power Supply, and the AG34970A devices immediately. Same, as in, I unplugged it from the original system and took it with me because the testing they needed to do, did not need it.
What is the difference? I have yet to figure that out. I installed all of the same software on both systems, same versions, same updates. However the new system, along with the changes I mentioned above, can successfully run all of the testing that I need for now. Auto-Addressing is still not working properly, so devices need to be manually selected, and a number of changes needed to be made to prevent SICL error handler from interrupting testing while it was running, but now that they are done, the system appears stable.