(...) but the sketch is an almost complete re-write of Emanuele's original codeThat sounds more than just some adjustments/patches to Emanuele's code. And if you compare both WaveyDipole's to Emanuele's code there are not too many sections that are similar, except the obvious parts that cover hardware compatibility.
To make EZGPIB recognize the adapter, it needs to have "GPIB-USB" string in the ++ver response.
thank you,
but does not compile. Errors are
AR488-0-45-10:758: error: invalid conversion from 'void (*)()' to 'void (*)(char*)' [-fpermissive]
plenty of them..
AR488-0-45-10:758: error: invalid conversion from 'void (*)()' to 'void (*)(char*)' [-fpermissive]
AR488-0-45-10.ino: In function 'bool gpibSendData(char*, uint8_t)':
AR488-0-45-10:1964: error: return-statement with no value, in function returning 'bool' [-fpermissive]
invalid conversion from 'void (*)()' to 'void (*)(char*)' [-fpermissive]
Kutte
I tried it with an Atmega328p NANO board. It works OK if I don't use ++auto command. If I use ++auto 1 command, everything gets slowed down, so even ++ver response is delayed by the timeout. Also the ++rst command makes it hang.
To make EZGPIB recognize the adapter, it needs to have "GPIB-USB" string in the ++ver response.
thank you,
but does not compile. Errors are
AR488-0-45-10:758: error: invalid conversion from 'void (*)()' to 'void (*)(char*)' [-fpermissive]
plenty of them..
AR488-0-45-10:758: error: invalid conversion from 'void (*)()' to 'void (*)(char*)' [-fpermissive]
error handling seems to have been downgraded to warnings after updating Arduino IDE fro 1.6.5 to 1.8.19
Kutte
AR488-0-45-10.ino: In function 'bool gpibSendData(char*, uint8_t)':
AR488-0-45-10:1964: error: return-statement with no value, in function returning 'bool' [-fpermissive]
invalid conversion from 'void (*)()' to 'void (*)(char*)' [-fpermissive]
Kutte
Version 0.45.11 uploaded. This should address the compiler warnings in Arduino IDE v1.8.8/1.8.19.0.
kutte, thanks for the update. The warning is interesting since it indicates a definition as it indicates that 'SPE' is defined elsewhere in the Arduino IDE support files. I will need to have a think about how to deal with this - probably will have to change all of my #define names.
I tried it with an Atmega328p NANO board. It works OK if I don't use ++auto command. If I use ++auto 1 command, everything gets slowed down, so even ++ver response is delayed by the timeout. Also the ++rst command makes it hang.
To make EZGPIB recognize the adapter, it needs to have "GPIB-USB" string in the ++ver response.
On the other hand, if I set the meter to TRIG AUTO, the program gives a continuous stream of voltage readings in the ++auto 1 mode. This maybe is useful, but its not the behavior one would expect. I think the problem maybe that the program issues a continuous stream of ++read commands in the ++auto 1 mode. My guess is that the buffer is getting delayed by ++read commands when no answer is supposed to come from the meter.
*idn?
++read
OEITHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15 /A02
fetch?
++read
m9.59916086E-01
:SENS:FUNC?
++read
bVOLT:DC"
I don't have Prologix's original software, but the behavior I observed with Girlando's code is that in ++auto 1 mode just one ++read command is issued after each command sent to the device. This generally make sense, since most GPIB instruments (except some meters in auto mode) don't have new data available in the buffer for reading at all times, only in response to a specific command.
On the other hand, for the case when data are available, it maybe useful to keep the auto mode as you have implemented it, simulating "Talk only" GPIB mode. So perhaps it would make sense to keep the continuous reading option that you have already implemented with something like ++auto 2 setting.
An even fancier implementation would be to look for "?" as the last character in the command sent to the meter. If there is a ?, then execute one ++read command, if not then don't execute the read command. Otherwise, the ++auto 1 mode can still cause errors if a command doesn't generate a response from the device.
would be nice to have a final schematic / wiring to be sure we dont miss something ??
I was just planning to use the wiring diagram included in the .docx file unless there is in fact a later version?
I get lots of warnings compiling on Windows 1.8.8.
The behaviour of the ++auto command has also been modified and now behaves as follows:
++auto 0 = auto off
++auto 1 = auto on - (Prologix style?), executes a read after every command* string sent to the instrument
++auto 2 = auto on - executes a read only after a query ('?') terminated command string
++auto 3 = auto on - executes continuous reads after the first ++read command issued
*the interface does not distinguish between instrument commands, queries or data being sent to the instrument.
Currently neither option executes a read after any ++ commands. As far as I can tell, the only command where this might be useful is perhaps after the ++trg command. If such functionality is something that might be useful then I would consider adding it. Any thoughts?
I tested the ++auto modes, they work great! One nice thing about ++auto 3 mode is that it allows in some situations to use a simple serial plotter or logger program without having to continuously issue commands to the instrument.
A few bugs I found:
++status command returns "Unrecognized command"
++auto state is not saved by ++savecfg command
++trg command is typically used to trigger multiple instruments simultaneously. So it would usually require a more complicated series of commands to read different addresses.
Same thing with the ''all" option only and the "default" and "more" shows nothing .......
AR488 GPIB controller, version 0.46.10, 02/03/2019
⸮5.49378228E-01
OEITHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15 /A02
⸮eysight Technologies,E36312A,MY57290136,1.1.1-1.0.2-1.05> *idn?
> ++read
OAfter loop:
2
0
0
Bytes read: 1
> ++read
MTHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15 /A02
After loop:
2
0
0
Bytes read: 54
I was able to set ranges, modes, and local/remote easily. Now to figure out how to script it so I can log measurements to a file.
Many thanks for creating and sharing this!
Communication with my HP 4192A impedance analyzer sees to work fine, but when I sent *IDN? to a Keithley 2001, the first 1 to 3 characters of the response were always wrong. Same with a Keithley 2010.
I just tried it again:Quote*idn?
++read
OEITHLEY INSTRUMENTS INC.,MODEL 2010,0632912,A15 /A02
fetch?
++read
m9.59916086E-01
:SENS:FUNC?
++read
bVOLT:DC"
Edit: I just noticed that the Keithley's display twitches when I send the ++read command. The instrument also clears the "REM" indicator, so it goes out of remote mode. Hmmm. Did I make a mistake in the wiring?
There maybe some timing parameters that need to be fine-tuned. For me it worked just fine with HP 3457A, but when I hooked it up to HP53310A, it would sometimes have problems, reading only the first character of the instrument's response string. If I upload the original Girlando's sketch to the same board, it works fine.
The key to low-cost solution is avoiding a custom circuit board.
Not really. A custom PCB would run around $2-$5 each depending upon quantity... well worth it as a time saver. Connecting 20+ wires to an Arduino is a tedious, error prone, unreliable task.Plus shipping, plus whoever wants to do it on a regular basis would need to charge something for their time. There have been a few attempts at such effort, I don't think they have been sustained for a long time. Its better to have a standard commercial hardware platform and then one can have open-source software that a few people contribute to. Of course one can also offer a complete product with a nice 3D printed case.
Still one would have to get the driver chips, populate the board, solder the connector wires or find a PCB-mounted connector.
This is about as simple a soldering project as it gets:
AFAIK GPIB uses open collector drivers and pull ups. Depending on the length of cable and instruments attached this can slow down the bus. Though maybe not part of the GPIB specs, it may thus be a good idea to have the option to run slower if needed. Usually it's better to run slow than with errors.Yes, it is specified to use open collector I/O with Thevenin termination to +5v (3k1) and to ground (6k2) which results in ~ 3.3 V floating voltage on the bus. The logic levels are the same as TTL, which means that >= 2.0 V shall be interpreted as a high and <= 0.8 V shall be a low. Very importantly, these voltages do not match the Arduino CMOS logic inputs, where > Vcc/2 (so 2.5V) is a high and < Vcc/2 is a low. The use of TTL-input buffers is a good solution. Powering the Arduino from a lower Vcc might also work (e.g. 4.0 V, so that Vcc/2 is 2.0 V). I'd also recommend adding termination to the Arduino side of the bus, even if it is only pull-up resistors, which will help to drive the high (floating) voltage higher.
Also the choice of the pull up resistors may have an effect.
with the ieee-844 male pcb connector from https://www.eztapzmarket.com/index.php?main_page=product_info&products_id=432924. (https://www.eztapzmarket.com/index.php?main_page=product_info&products_id=432924.) Price is currently under $10 for just the ieee-844 part but I did see them cheaper on ebay.
For others using a Mac, I strongly recommend using an official UNO (or a clone) which uses the ATmega16U2 as the USB-serial chip. I have tried a CH340-series version UNO clone and it just does not work, despite multiple workarounds and drivers on two completely different computers. One driver (the recommended version, in fact) crashed the Arduino IDE badly.
There maybe some timing parameters that need to be fine-tuned. For me it worked just fine with HP 3457A, but when I hooked it up to HP53310A, it would sometimes have problems, reading only the first character of the instrument's response string. If I upload the original Girlando's sketch to the same board, it works fine.
Would it be a big problem to move the SRQ and ATN pins to port B ? That's Uno / Nano pins in the range 8-13.
I have found that setting ++tmd parameter to 120 or larger makes the errors for HP53310A fairly infrequent, although they still happen once every few hundred commands or so even if ++tmd is set to 255. The other parameters don't seem to have any effect.
I bodged in at least one temporary GND connection now, and that seems to have fixed the "first character wrong" problem.
With the Keithley 2000, the read stops consistently after the first character is received now. When I send the ++read command again, I get the complete answer (so the first character is now on the screen twice) and the DMM beeps and shows Error -410 (Query interrupted).
Setting the ++tmd to 250 made that problem appear less frequently, about once in 20 ++read commands.
Lower tmd settings (like 100) did not help.
Changing both occurences of delayMicroseconds(AR488.tmd); to delayMicroseconds(10*AR488.tmd); and setting tmd to 50 seemed to fix the problem completely.
All the adapter boards I've seen (including mine) stick out horizontally behind the GPIB connector. That makes the boat-anchors stick out even farther from the wall and it's rather fragile. My next board will sit vertically. I'll post the new gerbers and layout files when I finish. Thanks again.
All the adapter boards I've seen (including mine) stick out horizontally behind the GPIB connector. That makes the boat-anchors stick out even farther from the wall and it's rather fragile. My next board will sit vertically. I'll post the new gerbers and layout files when I finish. Thanks again.
Thanks very much to waveydipole for pushing this forward. I know IEEE-488 is a bit unloved these days but this sort of hack could drag a lot of fine instruments into modern setups cheaply and easily. I much prefer putting a $5 adapter on every instrument than having a single interface and a lot of thick cabling. There are a lot of possible alternate implementations once we have good stable code - arduino, blue pill, cypress ez-usb (the cheap 'saleae clone' boards) & others.
The Nano can be a bit better than the Uno as it has all of port C available (it adds A6 and A7). So maybe it's not worth trying to keep them all the same but instead make a way to keep the code differences supported tidily - the existing structure is good except for the interrupt inputs which have the port hardcoded in the form of the mask register.
I should be able to get logic analyser traces (might take me a day or two) and also have hp instruments, but not sure I can get a 'good' trace. What signals do you want to see ? I do have wide analysers but the 8 bits of a Saleae is by far the easiest to acquire.
Sorry, I made a mistake connecting the logic analyzer for those captures. I had pin 7 connected to REN instead of ATN.
Here are the corrected versions.
Hi, I've built the Arduino GPIB interface and connected it to my Datron 1065. I've fired up EZGPIB and run the debug messages to test the setup. I know the arduino is on Com9 but the EZGPIB debug message is reporting that Com9 has been opened but no CTS signal detected and thereafter disregards the port. The AR488 manual identifies an issue with the ch340g chip not asserting a CTS signal and suggests a work around by connecting pin 14 to pin 9 on the chip. The Arduino I've got is a Uno R3 which uses an ATmega16U2 as the UART-USB adaptor, so is there a similar work around for the ATmega16U2 that will provide a CTS signal? Many thanks, Les.The best solution to the handshake flow control issue is to actually implement the handshake. I prefer to buy UNO clones that have the handshake lines broken out into a header, like the following example. Note the unlabeled 4-pin header near the CH340 chip. This has handshake lines on it. You can see that pins 9, 10, 12, 13 are connected to the header, and these are CTS, DSR, DCD, DTR. The software changes to implement the handshaking on GPIO pins are trivial.
For Agilent 33512 it does not automatically return an answer for *IDN? command, but returns an answer for FREQ? command. On the other hand, for Keithley DMM7510, it responds properly to *IDN? command but does not respond to read? command. In all cases, the answer can be obtained by sending an extra ++read command. See attached log file.
It would be really nice to add a couple of extra functionalities to this program. One would be to have a loop where it sends one string over and over and reads the response. One could have something called auto_str that can be set to save the command string (like "FETCH?") to be send to the instrument to get a response.
Is that because the data segment would be too big ?
The situation could be improved by putting any required command strings in program memory. This has been done for most of the internal strings though a scattering still need it. There are also some command and pointer tables in ram that could possible be moved.
There seems to be plenty of program memory available still.
Regarding the reply for ++auto 1, part of it could be due to getting out of sync with available data. But maybe adding a little delay between sending a command and executing a read will help. In my limited testing, if there was no immediate response, then executing another ++read command by hand would always return the correct answer.
Regarding the programming options, the first one was meant to be defined at run time. One would give a string (could have a few commands separated by semicolon, but probably much less than 100 characters) and expect a single response from the device. Whatever initial setup would be done by hand (either remotely or on front panel). The arduino code just needs to have one additional fixed loop with the user-defined string sent to the instrument and a ++read command.
For the second option I meant it to be hard-coded for a given instrument into the arduino sketch and compiled by the user.
//#define STARTUP#define STARTUP#ifdef STARTUP
const char start01[] PROGMEM = "++addr 7";
const char start02[] PROGMEM = "++auto 1";
const char start03[] PROGMEM = "*IDN?";
const char start04[] PROGMEM = "*RST";
const char start05[] PROGMEM = ":func 'volt:ac'";
const char * const startup_script[] PROGMEM = {
start01,
start02,
start03,
start04,
start05
};
#endifconst char start[i]xx[/i][] PROGMEM = "[i]commandstring[/i]";
const char * const startup_script[] PROGMEM = {
"command1",
"command2",
"command3",
};Code: [Select]const char * const startup_script[] PROGMEM = {
"command1",
"command2",
"command3",
};
const char startup_macro[] PROGMEM = {
/* Insert startup macro here ->*/
"++addr 7\n"
"++auto 1\n"
"*RST\n"
":func 'volt:ac'\n"
/*<-End of startup macro*/
};++macro 1
Thanks, I looked at the code and hope to play with it more this weekend. A macro would be useful in many cases, but I thought one could also do some more data processing. For example, if using an input scan card, read several channels and output them all on one line. Or measure voltage and current and then calculate power.
Regarding the reliability of ++auto command, it works well if one sets ++read_tmo_ms to 100 msec or longer. For slow commands I sometimes even increased it beyond 3 sec. Maybe a default value of 1 sec would be optimal with maximum allowed up to 30 sec.
For repeat command it would be nice to allow infinite repetition number, but still have a way to interrupt the loop. It could be programmed the same way as ++auto 3 command is programmed now, as part of the main loop.
Will have a think about that one. Also, a scan card would be required to develop and test this feature. I don't see any on eBay at the moment but I will keep an eye out in case one turns up for a reasonable price. In the meantime, I will see what I can do about doing some basic math like measuring power, however, this would assume that the DMM is capable of taking both measurements at the same time.These are just examples that came to mind (I happen to have an HP3457 with a scan card). Once there is a gpibReceiveDataToString() function that returns the GPIB string within the program the user can build an arbitrary complicated program (subject of limitations of the processor). I am planning to write a couple of such programs for the HP3457 but anyone could adapt it to their instruments and applications.
I've looked out for a keithley scan card but they're usually a bit pricy for my minimal likely usage. It's just the compulsion to fill that empty slot in the meter :)
However, the schematic is available and pretty simple. If you want a simple mux it would be easy enough to clone and I'm tempted to do that sometime. If you wanted to use it for thermocouple signals it might need a bit more care.
I've looked out for a keithley scan card but they're usually a bit pricy for my minimal likely usage. It's just the compulsion to fill that empty slot in the meter :)
However, the schematic is available and pretty simple. If you want a simple mux it would be easy enough to clone and I'm tempted to do that sometime. If you wanted to use it for thermocouple signals it might need a bit more care.
I have just tried version 0.46.20 of the AR488 firmware. It works great with my Keithley 2010 now! :-+
I'd prefer if the allowed values for the ++read_tmo_ms could be extended a bit though. If I use long integration time and averaging, it can take way more than 3 seconds before the DMM answers to a :READ? command...
//#define MACROS // Enable the user macros feature
//#define STARTUP // Enable the startup macroGlad to be able to use the AR488 software on my Nano 3.0 it gave me the opportunity to make a small 3d case using the Centronics Connector sold by Aliexpress. The design was done using 123D Design. I have attached the files below....
Here is one application of the ++repeat command. The HP3457A is a 6.5 digit multimeter, but one can obtain an extra digit for NPLC=10 or 100 by sending a separate GPIB command and adding the result to the previous reading:
https://www.eevblog.com/forum/testgear/the-mysterious-_7th-digit_-(hp-3457a-dmm)/msg385219/#msg385219 (https://www.eevblog.com/forum/testgear/the-mysterious-_7th-digit_-(hp-3457a-dmm)/msg385219/#msg385219)
This is generally somewhat annoying, so I implemented a different procedure: NPLC 1; NRDGS 10,1; TRIG SGL; - this gets 10 readings at NPLC 1 for each trigger. Then in the repeat command one sets: ++repeat 254 1 MATH STAT;TRIG SGL;RMATH MEAN; -this returns the mean of 10 measurements. It allows direct logging at 7.5 digit resolution, so any serial logger program can be used. It works a little slower, 0.9 sec for each such reading compared with 0.55 sec for one high-resolution reading at NPLC 10.
One could even use the DISP command of the multimeter to display the 7.5 digits on the display in real time if the multimeter response could be read into the Arduino program as a string and passed on as an argument to another GPIB command.
@WaveyDipoleWell the original credit goes to Emanualle Girlando. I sort of picked up, I believe, due to time constraints.
That's a very cool application. Congratulations! :-+
I had to verify if my PM6666 counter was working so I quickly built an AR488 with an Arduino Uno.Glad to hear it helped you out.
And eveything works!
I guess I can put one of these cheap Saleae 16 channels logic analyzer clones between the GPIB connector and the Arduino to look at some signals.Yes that is exactly what I did to help me with development. It can be a little puzzling to follow what is going on at first but its not that difficult. The probe wires do add a little noise, but it does work.
have you seen the newest pre-order arduinos ? : the Every, the nano 33 IOT / BLE .... they start at 10$ usd ... But not so sure they have 5 v i/o 's, seems to be yes on the mega datasheet.Not until just now when I saw your post!. Had a quick read up on it. I wonder whether pins A6 and A7 are fully functional on the basic 8-bit version? The 32-bit versions look interesting with BT and WiFi built in. And yes, more memory would certainly be useful.
Maybe more memory and speed would help future implementations ??
Does anyone know who designed the PCBs being sent out as part of the USA Cal Club?
(https://www.eevblog.com/forum/metrology/usa-cal-club-getting-started-user-guide/?action=dlattach;attach=777249;image)
Does anyone know who designed the PCBs being sent out as part of the USA Cal Club?
(https://www.eevblog.com/forum/metrology/usa-cal-club-getting-started-user-guide/?action=dlattach;attach=777249;image)
I'm hoping there is still one of the blank boards left when the USA Cal Club reference get to me. I getting pretty close on the list!
Since there's been a bit of interest in my board for the AR488 USB-GPIB project I thought I'd put the Diptrace and Gerber files up on Github (my first!)
If anyone wants to get their own GPIB adapter PCB, the files are at: https://github.com/vindoline/AR488-USB-GPIB (https://github.com/vindoline/AR488-USB-GPIB)
The gerbers have also been shared on OSHPark: https://oshpark.com/shared_projects/zpvaL7rz (https://oshpark.com/shared_projects/zpvaL7rz)
For what it's worth, I've frequently seen comments by much more experienced members decrying the fact that these inexpensive adapters don't use the correct GPIB line driver chips and that they probably won't work with multiple devices. I have my little adapter running an automated measurement setup with an HP 3488A switch, an HP 3456A voltmeter, a Fluke 8506A DMM and a Keithley 196 DMM with no problems! YMMV of course!
I don't have Prologix's original software, but the behavior I observed with Girlando's code is that in ++auto 1 mode just one ++read command is issued after each command sent to the device. This generally make sense, since most GPIB instruments (except some meters in auto mode) don't have new data available in the buffer for reading at all times, only in response to a specific command.
On the other hand, for the case when data are available, it maybe useful to keep the auto mode as you have implemented it, simulating "Talk only" GPIB mode. So perhaps it would make sense to keep the continuous reading option that you have already implemented with something like ++auto 2 setting.
An even fancier implementation would be to look for "?" as the last character in the command sent to the meter. If there is a ?, then execute one ++read command, if not then don't execute the read command. Otherwise, the ++auto 1 mode can still cause errors if a command doesn't generate a response from the device.
Hi vindoline,
Thanks for the links, this is exactly what I've been looking for.
I want to create an automated measurement setup just like what you have. In fact, we almost have exactly the same equipment. We are just off by one on the model numbers... I have an HP 3488A, 3457A, Fluke 8505A! (and a Keithley 197 but without GPIB) :-+
I want to setup a measurement network with 3488A to switch between DMMs and probes and automate the process via GPIB. I'm just getting started with this project, so I'm still learning the details.
How long has your setup been up and running? Was it difficult to configure and get it all going?
So here's what I am thinking as add ons to the basic AR488 FW functionality for junior league voltnut use.
real time clock
temperature and humidity sensor (possibly more than one)
4-8 port input relay matrix
2-4 port output relay matrix
generation of sampling requests with AR488 (from a table of commands downloaded to the board)
CSV format output stream
option to drive a pair of 44421A relay boards for input and output switching (for TiN and Andreas wannabes
I'd like to know if he'd accept conditional compilation of the features, and is there more functionality that would be desirable.
Something like a mega could do the task, tons of i/o to play with ?
Yes, all the above are good reasons to explore the Mega. This would allow rather more flexibility to develop additional features. It may be that the UNO/NANO version would remain the "basic" implementation, while the Mega would be the "advanced" version. It really depends what can be squeezed in to the lower end boards. I actually purchased a Mega a couple of months ago to play with, but am still working on the WiFi feature so haven't got around to that stage yet. It sounds like I should probably focus on this next and get it done sooner rather than later?
The purpose of my post was to see if there were other things I should be thinking about where to fit them when I study the source code. One thing that occurred to me yesterday was to have a multiline LCD panel option that would provide a scrolling display of what the interface was doing.
I had updated the manual some time ago, but it seems that the online copy did not get updated. I have now rectified this and details of the macro command can now be found in the manual.Thanks for updating the manual. It looks like it is missing the ++repeat feature, which is very handy.
Thanks for updating the manual. It looks like it is missing the ++repeat feature, which is very handy.
The bluetooth capabilities look really cool too, I should play with it sometime. I wonder if one can steal power from rarely used GPIB lines and use a small boost converter to generate 5V for power and make the adapter completely wireless.
Yes, that's what makes me wonder about it, otherwise it would not be interesting :) I think I have a plan for how to do it, we'll see if it works.I wonder if one can steal power from rarely used GPIB lines and use a small boost converter to generate 5V for power and make the adapter completely wireless.The IEEE488 connector does not provide any power, just signal pins and ground.
The AR488 is now available for the MEGA2560.
Thanks for doing the port. That will let me focus on various RTC clocks, T&H sensors and driving things like the 44421A boards.
Powering from GPIB might just be possible. I found accidentally in my Arduino Nano based GPIB-to-USB converter, that the ATmega328pb was “powered” through its IO lines when the USB power was off but the GPIB was left on.
Hi, this is very nice code, tnx! Is there any interest port it to ESP32 (if there is enough I/O), this will give native wlan support. I have tested adaper with ESP8266 and https://github.com/jeelabs/esp-link (https://github.com/jeelabs/esp-link). Esp-link is nicest code what I have found for IP/Wlan<->serial bridge.
Ramppa
| GPIB Signal Type | DC Characteristics |
| Input Voltage High | VIH = 3.4 volts typical, 2.4 volts minimum |
| Input Voltage Low | VIL = 0.22 volts typical, 0.4 volts maximum |
| Input Current High | IIH = 2.5mA maximum |
| Input Current Low | VIL = -3.2mA maximum |
| Output Voltage High | VOH = 3.4 volts typical, 2.5 volts minimum |
| Output Voltage Low | VOL = 0.22 volts typical, 0.5 volts maximum |
| Output Current High | IOH = -5.2mA maximum |
| Output Current Low | IOL = 48mA maximum |
The ESP32 is very cool. I have several, but not had time to get acquainted yet. But I question how useful a WiFi GPIB controller is given all the other wires required. Perhaps for remote data logging using a directional antenna, but around a small lab it's hard to see much benefit.
Now, a large student lab with multiple instruments and computer workstations is another matter. I can see a lot of use for it in an academic setting.
Wired has maybe still the advantage that power can be supplied also. The low cost POE switches found on Ali-express combined with a low-cost Ethernet GPIB adaptor seem like the ideal alternative to GBIB cabling equipment together.
Since I already have GPIB cables between instruments, I might one day turn a Leonardo ETH into an Ethernet gateway. I imagine the AR-488 firmware would port over to the 32u4 without too much trouble. Then, it's a question whether there's enough code space for the Ethernet part.
Since I already have GPIB cables between instruments, I might one day turn a Leonardo ETH into an Ethernet gateway. I imagine the AR-488 firmware would port over to the 32u4 without too much trouble. Then, it's a question whether there's enough code space for the Ethernet part.
From what I have read, I think the hardware of the arduino as it is cannot handle daisy chained devices on GPIB. For this to work, additional hardware needs to be implemented.
It helps to read the datasheets and the GPIB electrical spec.
75161 or 75162 type line drivers could pump it to 48 ma ...
https://www.ti.com/lit/ds/symlink/sn75als161.pdf (https://www.ti.com/lit/ds/symlink/sn75als161.pdf)
Hunt the wumpus. Classic!
WaveyDipole
I'm looking at the Mega 2560 wiring. Is there any reason not use 24 pins on the two row header at the end? It's been a couple of years since I looked at the board details, but a 24 pin ribbon cable on the 2 x 18 header at the end feeding the GPIB bus connectors via a ribbon cable seems a lot cleaner than the current wiring for the 2560. Though perhaps not as convenient if one wants to use a stock LCD display.
Is there a pin assignment constraint that prevents doing that? A
On general principle I'd like to merge the Uno and Mega versions so there is only a single point of maintenance. So I'll be looking closely at what is needed to achieve that.
I also *very* much want to implement "++lon" for use as part of a test harness.
For a wide range of reasons, I think that ethernet connectivity is best done with a Pi or Beagle.
Could I suggest looking into supporting ESP8266 or even better ESP32 boards as well? This would open the possibility of connecting via wifi and in the case of the ESP32, bluethooth as well :)
Just a quick note on the electrical specifications for the 328P.
The logic low input voltage for IEEE-488 (as for TTL) is max 0.4V. Looking at figure 29-8 in the datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-7810-Automotive-Microcontrollers-ATmega328P_Datasheet.pdf) for the 328P one can see that in order to meet that specification you can't sink more than ~17mA @25°C and if we're going by the "typical" low level voltage of 0.22V then it's more like 9mA.
Mark,
Thanks, I grabbed my numbers from here (http://www.interfacebus.com/Design_Connector_GPIB.html) but I'll happily stand corrected. Perhaps they've changed the voltages in later versions of the standard meaning older instruments might not be that allowing - but I'm speculating.
I think this AR488 and the work that has gone in to it is great. My point was simply that the 328P, in reality, is a bit more limited than what was suggested in a previous message.
@mlefe :
Did you modify it inline for the blue pill or isolate the register access
?
I did a 32u4 port of an earlier version of the code but never got around to testing it. When I redo it I'd prefer to break the hardware-specific parts out into macros so they can be swapped easily, but if someone else already did that I'd rather build on their work.
Well, the good news is that I've talked too soon: I put together Emanuele's version on an Arduino UNO and I'm able to communicate with my devices again...
SO... back to troubleshooting the STM32 version.
@rhb, I believe the 3.3V should be fine because when I was testing my 34401a I've realised that it's using 3V for the HIGH (it uses a 75ALS162 as driver: it receives 5V internally but puts around 3V in the GPIB port).
I'll let you guys know if I make any progress.
How are you programming the blue pill ?Everytime I receive a new one, I perform these steps to install the firmware from stm32duino:
I have some here but haven't really got a usable workflow for them. But I have got a logic analyser and even one of those old HPIB analysers bitseeker mentions.
(very puzzled as to why I was entering a newline every time I hit '?'. Thought it was the forum software but it was because of a bit of hot glue that had fallen between the shift and return keys ...)
So I'd think it was OK for 2 loads and possibly 3 (unspecified, but there's a good margin at 2 loads) but not for 6 or 7.
I'm not really sure why they specify CMOS and TTL ports as though they're something different. As far as I can tell those figures apply to all ports except for 3 specific pins which have a 3mA limit. The CMOS/TTL designation just seems to be to distinguish the spec of 2.4V for TTL and Vdd - 0.4 for CMOS. Vdd - 0.4 would still give at least 2.4V out down to a supply of 2.8V but spec says its maintained to 2.7V Vdd. At 3.3V and 8mA it should be at least 2.9V.
Everytime I receive a new one, I perform these steps to install the firmware from stm32duino:
1. I connect a FTDI to the blue pill
2. I move the "upper" jumper to 1
3. I connect the FTDI to a USB port. I verify that it appears as "Prolific USB To Serial Port (COM 6)" (6 or whatever other port)
If this step fails, I download PL2303_64bit_Installer that installs version 3.8.18.0 (this one works for Win10)
4. Then I go to "C:\Program Files (x86)\Arduino\hardware\Arduino_STM32\tools\win"
5. I then execute this line: stm32flash.exe -w ..\..\STM32F1\binario\generic_boot20_pc13.bin COM6 (6 is an example, you should use the previous port)
6. I shift the upper jumper back to "0"
Then I use the arduino IDE with the following settings (in the "Tools" menu):
Board: Generic STM32103C
Variant: STM32F103CB (20k RAM, 128K Flash)
CPU Speed: 72MHz
Upload Method: STM32duino Bootloader
Sometimes when I'm uploading the sketch it gets stuck waiting for the DFU interface, if that happens I quickly reset it (so it starts in DFU mode) and that's enough to make it work.
It seems that the CDC serial port driver used by the arduino (and most other) USB virtual serial ports doesn't support CTS from device to host. This isn't a shortcoming of the serial port, it's not present in the CDC spec and hence not available in the OS driver. So it isn't possible to trivially add it to satisfy EZGPIB.There is a simple way to edit EZGPIB executable to make it ignore the CTS/RTS control. See http://www.dalton.ax/gpib/ (http://www.dalton.ax/gpib/) at the bottom under "Notes".
There is a simple way to edit EZGPIB executable to make it ignore the CTS/RTS control. See http://www.dalton.ax/gpib/ (http://www.dalton.ax/gpib/) at the bottom under "Notes".
As for project enclosures, I actually bought some old, dead HP gear just for repurposing their cases. :-+
This box fits perfect for this
(https://ae01.alicdn.com/kf/H19e317674568486b90a703f935ef818bt.jpg)
https://pt.aliexpress.com/item/4000137043277.html?spm=a2g0o.cart.0.0.3e523c00kfgSjD&mp=1
As for project enclosures, I actually bought some old, dead HP gear just for repurposing their cases. :-+
The horror ! You shouldn't have told us that :). You're going to get lynched in the TEA thread now ..
I hope it's really useless stuff like (imho) bit error rate testers and the like. I generally find that old equipment I buy for parts gets mended instead. It's too tempting to just have a go at it.
It's finished! :-)
I got my enclosures today and my first AR488 GPIB-USB interface is completed. This one is for AR488 FW development and to operate a stack of 2x 34401As. It will later move to the 2x 3478As when I build the 44421A 20 channel switch for monitoring voltage references.
This box fits perfect for this
https://ae01.alicdn.com/kf/H19e317674568486b90a703f935ef818bt.jpg
https://pt.aliexpress.com/item/4000137043277.html?spm=a2g0o.cart.0.0.3e523c00kfgSjD&mp=1
I was already looking for a GPIP adapter to erase the errorlog of my newly purchased TEK TDS744A. This ran over, because the device ran for years with defective Attenuators and always generated new errors. I repaired the Attenuators. Then came across the AR488 thread and found, that I have everything here to build the part. Within an hour I finished it, programmed the Arduino Mega and I was able to establish contact with the TDS744A. I was very surprised how easy it was. Entered a few commands and already the errorlog of the TDS744A was empty. Great!!!! Thanks to Emanuele (and Helpers) for this great project.
To fix the plug, I had to come up with something, because it can not be fixed without the metal case. So I designed two panels and printed them out. The plug then comes as a sandwich between these panels and holds bombproof. In addition, a small box for the Arduino Nano and finished the part. The box could have been a little smaller. If you want the files, I can still post them.
I will next endeavour to complete the code for the ESP8266 module and then move on the the ESP32.
The HP 37203A HP-IB Extender I bought for the case is full of 7400 series logic chips.
GPIB was *implemented* with 5 V TTL. So it is *completely* compatible with 5 V TTL.
The HP 37203A HP-IB Extender I bought for the case is full of 7400 series logic chips. 3.3 V logic did not even exist when HP-IB was designed and went to market.
Logic high for 5 V TTL is about 3.3 V. Read the first chapter of Don Lancaster's "TTL Cookbook".
Maybe to help others you could write your solution / code change ??
100us is an awful long time given that the instrument is supposed to assert DAV when the data is there to be read. I'd be interested to see some logic analyser traces of the bus, if that's possible.The instrument don't check if data pins reached desired logical level ... I'll try to scope some offending pin and check also what's happening as soon as I have few minutes.
It's possible the code should set the data lines to pullup when it prepares for data by asserting NDAC. Then they'd have longer to reach their value. However, it does, I think set them to input then : so the bus terminators (should be on every device) should have already done that.
Maybe the ILX LTD-5910 is also a non-conforming interface and doesn't have any. Do you have any other instruments you could put on the same bus ?
I proposed a similar solution to the OP on his GitHub few hours ago, just setting pull-up at the same time of NRFD is asserted ... assuming NRFD and data lines have the same propagation time this should work and will also avoid to add any delay. I don't know GPIB protocol so in deep to understand if this can be done or can cause some problems elsewhere (waiting the author response).
.....
EDIT: tested this solution and is working. More details on projects GitHub.
Along the same lines, it would also be possible to set the pins in input pullup mode with output values set to zero (assuming that doesn't turn them into input pulldowns - it might) and switch them into output mode for any that need to be pulled low. This emulates an open collector drive. It's both more correct electrically for GPIB and will also execute faster (only one port direction register write instead of a direction and a data register).
However the weak input pullups - although hopefully strengthened by the other terminators on the bus - might be too light and result in too slow a rising transition.
Is there a way to receive a status code back after a read or write? It seems like there's no way with the ProLogix commands to know if a write failed, or when the write completes?
What's the maximum message length? To have longer messages, can I disable EOI/terminators and send multiple shorter messages?
I'm thinking about writing a VXI-11 wrapper software for this project, so that GPIB devices could be used through the standard VISA API. However, I have a few questions about the computer side of the driver that I'm hoping someone can answer:...
- Is the Arduino Micro the only MCU that can perform flow control so that the MCU's buffers are not overrun (e.g., during large binary transfers)? The Uno seems to have no flow control, so data could be lost if the host sends too quickly?
#if defined (__AVR__) && not defined (AR_SW_SERIAL)
// Use serial interrupt handler
#define USE_SERIALEVENT
#endif
// #define USE_SERIALEVENT
Thanks for debugging this. I don't think WaveyDipole has an instrument that transfers data in large pages making it difficult to test (though he does seem to be acquiring additional stuff).
Yes, I mentioned this in the original 32u4 patch which also handled it on the top of loop(). It looks as though it got lost in the transition to not use it and then use it again. It did work on at least one of the combined releases but I haven't tested all of them.
I think it's actually pretty useless as it stands (especially as it's not supported on the 32u4 for no very good reason) and should be considered as only a style thing for code that's written that way. For compatibility it has no particular processing speed advantages as long as loop() executes quickly. Maybe one day it could be handled with a separate task but that's not going to happen on an AVR.
Many thanks for the update!
The default settings work fine with my HP8593E. :-+
Could you possibly add a simple serial number or id function like ++id or ++serial, where the adapter answers with a predefined/hardcoded identifier string like "HP8593E"?
The idea is to have one personalized adapter per instrument instead of heavy GPIB cabeling. This would also solve the "one instrument on bus in switched off state" problem.
The downside will be many com ports on the PC side. The identifier string would help tell them apart.
Funnily enough I was contemplating adding something like an ++id command to return a response in reply to the *id? sequence. I figured that something like that might be useful in the case of older instruments that do not respond to an ID request. The string would be of limited length, perhaps 20-30 characters.
The original idea for ++setvstr in conjunction with ++ver, was to set a custom string in response to the ++ver command so that EZGPIB, KE5FX and other GPIB programs can get the expected reply string they are "looking for" (e.g. "GPIB-USB") in order to identify a Prologix interface, however this feature could also be used to provide a means to identify the connected instrument.
After ++setvstr you have to do a ++savecfg. That saves the adapter configuration in EEPROM.
In keeping with other Prologix commands, one might expect ++id to return the currently set ID string, although naturally, *idn? would do that anyway, in which case the exception perhaps makes sense. However, one could also do something like ++id # or similar to delete.
Since these strings (ver, id and serial) are not likely to be changed very often, I could set it up so that they are saved independently as you suggest.
I would like to support something like this at the USB level in the 32u4 version
QuoteI would like to support something like this at the USB level in the 32u4 version
You mean something that would appear as a "friendly name" of the corresponding COM port? Right now, it appears as "Arduino Leonardo".
I am not very familiar with the Arduino IDE environment. I assume, the USB endpoint is defined somewhere in the bootloader and it would have to be changed there.
An alternative would be to set up a second USB CDC endpoint, but I have no idea how this would be done in Arduino without interfering with the bootloader...
Btw, where would the bootloader source code be found and how does it get included into each sketch being uploaded?
As promised here are two logs of plot requests from an HP and a Tektronix spectrum analyzer with an original Prologix V6 adapter.
The requests were performed with the KE5FX plotter emulator software.
Indeed, in the communication there are lots of characters < 0x20 sent by the instrument, particularly some LF.
Btw, my AR488 code modification that waits for CR+LF works with both instruments.
Sorry, yes meant *idn? (or *IDN?). Have edited my previous post.
After ++setvstr you have to do a ++savecfg. That saves the adapter configuration in EEPROM.
In keeping with other Prologix commands, one might expect ++id to return the currently set ID string, although naturally, *idn? would do that anyway, in which case the exception perhaps makes sense. However, one could also do something like ++id # or similar to delete. I will have a think about that.
Since these strings (ver, id and serial) are not likely to be changed very often, I could set it up so that they are saved independently as you suggest. What do others think?
I have used a very rudimentary ESP8266 code from here:
https://github.com/roboremo/ESP8266-WiFi-UART-Bridge (https://github.com/roboremo/ESP8266-WiFi-UART-Bridge)
Not very comfortable as it can only be configured by changing the source code and you have to find out the dynamically assigned IP address somehow.
I'm not very experienced with ESP8266 programming.
So, a proof of concept! But that's the way I want to talk with my instruments eventually! :)
I can't see the numbers on the TO-220 device, but I presume that since the Pro Micro has no on-board 3.3V regulator, that you had to use an external regulator?
Do the 4 resistors form a pair of dividers to convert the serial TTL level signal on the Arduino to 3.3V level for the ESP8266?
I have for some time been working on my own version of the TCP to UART concept...
/*** MEGA 32U4 based boards (Micro, Leonardo) ***/
#elif __AVR_ATmega32U4__
/*** Board/layout selection ***/
#define AR488_MEGA32U4_MICRO
/*** Serial ports ***/
// Comment out if using RXI, TXO pins
#define AR_CDC_SERIAL
// The Mega 32u4 default port is a virtual USB CDC port named 'Serial'
#ifdef AR_CDC_SERIAL
#define AR_SERIAL_PORT Serial
#else
#define AR_HW_SERIAL
#define AR_SERIAL_PORT Serial1
#endif
esptool.py v2.8What does this want to tell me?
Serial port COM5
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: bc:dd:c2:47:40:6b
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Compressed 318336 bytes to 223301...
Writing at 0x00000000... (7 %)
Writing at 0x00004000... (14 %)
Writing at 0x00008000... (21 %)
Writing at 0x0000c000... (28 %)
Writing at 0x00010000... (35 %)
Writing at 0x00014000... (42 %)
Writing at 0x00018000... (50 %)
Writing at 0x0001c000... (57 %)
Writing at 0x00020000... (64 %)
Writing at 0x00024000... (71 %)
Writing at 0x00028000... (78 %)
Writing at 0x0002c000... (85 %)
Writing at 0x00030000... (92 %)
Writing at 0x00034000... (100 %)
Wrote 318336 bytes (223301 compressed) at 0x00000000 in 23.7 seconds (effective 107.4 kbit/s)...
Traceback (most recent call last):
File "C:\Users\baier\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3/tools/upload.py", line 65, in <module>
esptool.main(cmdline)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2938, in main
operation_func(esp, args)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2398, in write_flash
res = esp.flash_md5sum(address, uncsize)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 104, in inner
return func(*args, **kwargs)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 691, in flash_md5sum
timeout=timeout)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 369, in check_command
val, data = self.command(op, data, chk, timeout=timeout)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 347, in command
p = self.read()
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 292, in read
return next(self._slip_reader)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2045, in slip_reader
raise FatalError("Timed out waiting for packet %s" % waiting_for)
esptool.FatalError: Timed out waiting for packet header
esptool.FatalError: Timed out waiting for packet header
I would like to support something like this at the USB level in the 32u4 version (so it appears in dmesg and lsusb listings) , though that's not trivial as the current USB driver doesn't support custom names.
If I did that, should it hang off the proposed ++id idea or should it be yet another level of naming ?
I have just run a test with AR488-wifi, so far without GPIB adapter.
I could flash the code but I did get a strange error message after flashing was complete:Quoteesptool.py v2.8What does this want to tell me?
Serial port COM5
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: bc:dd:c2:47:40:6b
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 1MB
Compressed 318336 bytes to 223301...
Writing at 0x00000000... (7 %)
Writing at 0x00004000... (14 %)
Writing at 0x00008000... (21 %)
Writing at 0x0000c000... (28 %)
Writing at 0x00010000... (35 %)
Writing at 0x00014000... (42 %)
Writing at 0x00018000... (50 %)
Writing at 0x0001c000... (57 %)
Writing at 0x00020000... (64 %)
Writing at 0x00024000... (71 %)
Writing at 0x00028000... (78 %)
Writing at 0x0002c000... (85 %)
Writing at 0x00030000... (92 %)
Writing at 0x00034000... (100 %)
Wrote 318336 bytes (223301 compressed) at 0x00000000 in 23.7 seconds (effective 107.4 kbit/s)...
Traceback (most recent call last):
File "C:\Users\baier\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3/tools/upload.py", line 65, in <module>
esptool.main(cmdline)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2938, in main
operation_func(esp, args)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2398, in write_flash
res = esp.flash_md5sum(address, uncsize)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 104, in inner
return func(*args, **kwargs)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 691, in flash_md5sum
timeout=timeout)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 369, in check_command
val, data = self.command(op, data, chk, timeout=timeout)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 347, in command
p = self.read()
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 292, in read
return next(self._slip_reader)
File "C:/Users/baier/AppData/Local/Arduino15/packages/esp8266/hardware/esp8266/2.6.3/tools/esptool\esptool.py", line 2045, in slip_reader
raise FatalError("Timed out waiting for packet %s" % waiting_for)
esptool.FatalError: Timed out waiting for packet header
esptool.FatalError: Timed out waiting for packet header
I'm not sure I fully understand what should work already and what shouldn't work yet.
I could connect in AP mode. The configuration pages are extremely nice! :-+
When this is fully functional, it is definitely going to be my favorite! :)
I could only connect to port 80, but not to port 8488. I'm using YAT as TCP client.
I could not send anything over from YAT to the UART monitored with the Arduino serial monitor.
Is the bridge function already working?
I could not switch to station mode. The chip continued to stay in AP mode.
When I toggled switches, went to another tab and returned, then the switch settings were in default position again.So, it seems changes are not accepted yet.
Any hints are welcome.
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
esptool.FatalError: Failed to connect to ESP8266: Timed out waiting for packet header
Pass-though is initially disabled but can be enabled with the slide switch and then clicking Apply.
I was using version 1.8.9 of the IDE, 2.5.2 of the ESP8266 library
e72c44891aed2416 55398a91cdbea4a0 | .,D...$.U9......
703642490fb0860d f0bc0d4f96963568 | p6BI.......O..5h
1dac81a9610df396 b286831ed6f0ff16 | ....a...........
3007c807cab900e5 0280722540f12740 | 0.........r%@.'@
f118a0f80cd0392b dee0331d4f000088 | ......9+..3.O...
4baf88c0 | K...
TRACE +1.839 Read 1 bytes: c0
TRACE +0.000 Read 8 bytes: 0111020000000000
TRACE +0.010 Read 1 bytes: 00
TRACE +0.000 Read 2 bytes: 00c0
TRACE +0.000 Received full packet: 01110200000000000000
Wrote 324640 bytes (225952 compressed) at 0x00000000 in 25.5 seconds (effective 101.9 kbit/s)...
TRACE +0.000 command op=0x13 data len=16 wait_response=1 timeout=3.000 data=0000000020f404000000000000000000
TRACE +0.000 Write 26 bytes:
c000131000000000 000000000020f404 | ............. ..
0000000000000000 00c0 | ..........
TRACE +1.729 Read 1 bytes: c0
TRACE +0.000 Read 8 bytes: 0113120000000000
TRACE +0.380 Read 1 bytes: 42
TRACE +0.000 Read 18 bytes:
afae3076ff198867 57751062f1424e00 | ..0v...gWu.b.BN.
00c0 | ..
TRACE +0.000 Received full packet:
0113120000000000 42afae3076ff1988 | ........B..0v...
6757751062f1424e 0000 | gWu.b.BN..
Hash of data verified.
Leaving...
TRACE +0.009 command op=0x02 data len=16 wait_response=1 timeout=3.000 data=00000000000000000040000000000000
TRACE +0.000 Write 26 bytes:
c000021000000000 0000000000000000 | ................
0000400000000000 00c0 | ..@.......
TRACE +0.000 Read 1 bytes: c0
TRACE +0.000 Read 11 bytes: 01020200000000000000c0
TRACE +0.000 Received full packet: 01020200000000000000
TRACE +0.000 command op=0x12 data len=4 wait_response=1 timeout=3.000 data=01000000
TRACE +0.000 Write 14 bytes: c0001204000000000001000000c0
TRACE +0.010 Read 1 bytes: c0
TRACE +0.000 Read 11 bytes: 01120200000000000000c0
TRACE +0.000 Received full packet: 01120200000000000000
Hard resetting via RTS pin...
I have downgraded to ESP library 2.5.2.
The upload log looks very different now, lots of hex code, I just include the end:
....
Looks like the upload was successful. But no change to functionality.
Changes on tabs General and wifi do not take effect.
Please let me know if I can do further tests at this point.
Best regards
Sketch uses 320212 bytes (64%) of program storage space. Maximum is 499696 bytes.
Global variables use 51956 bytes (63%) of dynamic memory, leaving 29964 bytes for local variables. Maximum is 81920 bytes.
esptool.py v2.6
2.6
esptool.py v2.6
Serial port /dev/ttyUSB2
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: cc:50:e3:55:db:52
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0340
Compressed 324368 bytes to 225898...
Writing at 0x00000000... (7 %)
Writing at 0x00004000... (14 %)
Writing at 0x00008000... (21 %)
Writing at 0x0000c000... (28 %)
Writing at 0x00010000... (35 %)
Writing at 0x00014000... (42 %)
Writing at 0x00018000... (50 %)
Writing at 0x0001c000... (57 %)
Writing at 0x00020000... (64 %)
Writing at 0x00024000... (71 %)
Writing at 0x00028000... (78 %)
Writing at 0x0002c000... (85 %)
Writing at 0x00030000... (92 %)
Writing at 0x00034000... (100 %)
Wrote 324368 bytes (225898 compressed) at 0x00000000 in 19.9 seconds (effective 130.2 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...Regarding the hex data in the output, this will be because you have verbose mode on.
Might I ask what browser and version thereof you are using please and whether this is on Windows, Mac, iOS, Linux or Android? Also can I confirm that you do have JavaScript (not Java) enabled in the browser?
./esptool.py --port /dev/ttyUSB2 write_flash 0x000000 mybinary.bin
python esptool.py --port /dev/ttyUSB2 write_flash 0x000000 mybinary.bin
I have just run a test with AR488-wifi, so far without GPIB adapter.
I could flash the code but I did get a strange error message after flashing was complete:
I have uploaded version 0.48.08 which now includes updated support for auto-configuration of the Bluetooth HC05 module
UPDATE: a further test showed that is sufficient to delete /.arduino15/packages/esp8266.
esptool.FatalError: Timed out waiting for packet header
I have uploaded version 0.48.08
I don't see any gain in using a Leonardo for a bluetooth version
Btw, do I find current connection info for the HC-05 to the Leonardo in the package Bluetooth document?
Btw, where should I connect the BT control pin to my Leonardo? As far as I can see, all port lines are occupied by GPIB. There are only two free board pins, which are RST and RAW. I assume RST goes to the reset pin. Can this be reconfigured as port line / GPIO? What is the RAW pin?
Best regards.
QuoteUPDATE: a further test showed that is sufficient to delete /.arduino15/packages/esp8266.
I have just done this and reinstalled ESP8266 2.6.3 package from scratch.
I still get the same error message at the end of the upload process:Quoteesptool.FatalError: Timed out waiting for packet header
QuoteI don't see any gain in using a Leonardo for a bluetooth version
Well, ultimately I want wifi and not Bluetooth. I just wanted to test the new firmware.
Taking this further: It shouldn't be too hard to make the firmware work simultaneously with both interfaces, i.e. accepting incoming messages from both channels CDC USB and hardware UART and sending outgoing messages to both simultaneously. In this case, reconfiguration would be unnecessary altogether.
but if you want to modify it just ask me for the kicad sources
The Uno layout has two pins spare (6 and 13) and I used pin 6 in my tests early on.
The Micro Pro has rather different pin numbering so some modifications would be necessary to allow the current Micro Pro 32u4 layout to work on the Leonardo.
Taking this further: It shouldn't be too hard to make the firmware work simultaneously with both interfaces, i.e. accepting incoming messages from both channels CDC USB and hardware UART and sending outgoing messages to both simultaneously. In this case, reconfiguration would be unnecessary altogether.
Yes it can be done and I have put together some code that can do that for hardware ports but not got as far as including CDC or SoftwareSerial ports yet. I wasn't sure how much value this would be to this project, although I had thought that such a capability might be useful for diagnostics.
@WaveyDipoleQuoteThe Uno layout has two pins spare (6 and 13) and I used pin 6 in my tests early on.
Indeed, the Uno has spare ports. The Leonardo Pro Micro has exactly 16 port lines (+2 serial hardware lines), so the HC-05 will not work on the Pro Micro as no spare line for the control pin.QuoteThe Micro Pro has rather different pin numbering so some modifications would be necessary to allow the current Micro Pro 32u4 layout to work on the Leonardo.
This may be a misunderstanding. For me, the Pro Micro and the Leonardo are the same board. I only have an At32U4 Pro Micro board here which is detected as Leonardo by the Arduino IDE. So, I assumed this is synonymous.
I do also have an Uno board, so I may still test the HC-05. But I haven't currently wired it up to a GPIB connector.
GPIB pass through works nicely, now.
I still cannot switch it to client mode. If I do, the AP mode is switched off but reactivated quickly again.
And I'm also having an issue of frequent disconnects, when the ESP module is hooked to the AR488.
Btw, I'm using this combo of ESP-01 and USB-to-serial programming adapter:
https://www.amazon.de/AZDelivery-ESP8266-ESP-01-USB-Adapter-Arduino/dp/B078J7LDLY (https://www.amazon.de/AZDelivery-ESP8266-ESP-01-USB-Adapter-Arduino/dp/B078J7LDLY)
Hi, I have just tried your new firmware version with the debug switches on.
Funny thing: As soon as I activated the debug switches, the upload errors disappeared.
But I'm afraid still no connection to my home AP.
Also, I fear I cannot read anything from the debug log.
I attach it in hope that you may learn something from this.
Btw, my password is quite long. In fact it is longer than the input field. Is there a limit on the length of the password?
I assume, WPA2 should be no problem as the simple bridge code I initially used, did connect to my home AP.
And just to be sure I do not make a stupid mistake:
I switch wifi mode to client.
I activate DHCP for automatic IP address assignment.
I enter the SSID of my home AP into the ESSID field.
I enter the password of my home IP into the Password field.
I hit the Apply button.
That's where the log starts.
The log ends, when the ESP falls back to AP mode.
Which board profile are you using? I upload using "Generic ESP8266 Module".This is what I use, too.
If your password is longer than 19 characters that could be the problem. The password length in my code is 20 characters (minus one for the NULL terminator).Then, we have found the reason. My password is longer than the limit. Can this be changed? Are you short in non-volatile memory?
but if you want to modify it just ask me for the kicad sources
Success! The little beast is connected to my home network now.
Many thanks for the new version!
One find:
I did fire it up with DHCP activated and apparently, an IP address was automatically assigned.
When I then entered the wifi configuration tab via my home network, the DHCP switch was in off state again, but the gateway and netmask input fields were greyed out.
And after power cycling the ESP, it is back in AP mode. I believe you mentioned that this is still work in progress, right?
I have just tested static IP without DCHP. This works nicely, too. :-+
For the records:
I have solved the ESP8266 connectivity problem when hooked up to the AR488 adapter:
My LF33 3.3V voltage regulator was oscillating. The output blocking cap was broken, fixed now.
The problem had nothing to do with the ESP firmware, which works great.
And I have found a way to power the AR488+ESP8266 combo directly from my HP8593E spectrum analyzer.
It has an external keyboard PS2 socket, which provides 5V power. :)
Best regards.
It only took the weekend to get my script up and running. Most of that time went on battling with the fact that you can't let the serial port get closed as that resets the Arduino the next time the port is opened.
It only took the weekend to get my script up and running. Most of that time went on battling with the fact that you can't let the serial port get closed as that resets the Arduino the next time the port is opened.
It is possible to prevent the reset as detailed here:
https://playground.arduino.cc/Main/DisablingAutoResetOnSerialConnection/
Also on the Mega2560 it is possible to use one of the other serial ports connected to one of those FT232RL modules.
Not seen GNUplot before. Will have to have a look at that. Thanks for the picture.
2020-02-16 15:35:38,24.17,40.30,983.74,+1.0183911
2020-02-16 15:35:46,24.17,40.30,983.74,+1.0183908
2020-02-16 15:35:54,24.17,40.30,983.74,+1.0183906
2020-02-16 15:36:02,24.17,40.30,983.74,+1.0183907
2020-02-16 15:36:10,24.17,40.30,983.74,+1.0183908
2020-02-16 15:36:18,24.17,40.30,983.74,+1.0183909
2020-02-16 15:36:26,24.17,40.30,983.74,+1.0183906
set lmargin screen 0.2
set datafile separator ","
set terminal png size 1800,800
set multiplot
set title "7061 Weston Cell Readings"
set xlabel "Time"
set xdata time
set timefmt "%Y-%m-%d %H:%M:%S"
set format x "%H:%M"
set key off
set grid
set ylabel "Temperature" offset 7,0 textcolor rgb "red"
set format y "%10.1f"
plot "WestonLog.csv" using 1:2 with lines lw 2 lt rgb "red"
set ytics offset -8,0
set ylabel "Humidity" offset -1,0 textcolor rgb "green"
set format y "%10.1f"
plot "WestonLog.csv" using 1:3 with lines lw 2 lt rgb "green"
set ytics offset -16, 0
set format y "%5.1f"
set ylabel "Pressure" offset -14,0 textcolor rgb "blue"
plot "WestonLog.csv" using 1:4 with lines lw 2 lt rgb "blue"
set ytics offset -24, 0
set format y "%10.7f"
set ylabel "Voltage" offset -21,0 textcolor rgb "violet"
plot "WestonLog.csv" using 1:5 with lines lw 2 lt rgb "violet"
unset multiplot
I have uploaded the current version to the AR488 Git here:
https://github.com/Twilight-Logic/AR488/tree/master/src/AR488-ESP8266-addon
For now I am using EEPROM functions but was contemplating moving to using spiffs.
So I've gotten this firmware working nicely to dump plots from my 8594E into the 7470A plotter emulator, it works beautifully with no problems at all.
Care to share the 8594E script & settings ?
/Bingo
*edit: So I looked in the code and realized that ++lon is implemented, I don't know why I had it in my head that it was not.
I played around with the 7470A plotter emulator and found that if I select request plot from device then it will assert NDAC and then the scope will start sending the plot however the emulator then interprets that data as the instrument name.
The hardcopy format is correct, the scope sends HPGL and the plotter emulator renders it just fine. The problem is that the line that tells the scope to start sending does not assert when the plotter emulator is set to listen on all addresses. The TDS400 series only support hardcopy in talk-only mode and do not address a plotter at a specific address.
++ver
AT488 GPIB-USB version 4.99
++auto
Unrecognized command
++eos 0
++mode 0
++addr 5
++eoi 1
++ver
AT488 GPIB-USB version 4.99
++auto
0
++auto 1
++eos 0
++mode 0
++eoi 1
#define DISABLE_SSL.I have also found 0.04.11 indicated here https://github.com/Twilight-Logic/AR488/blob/master/src/AR488-ESP8266-addon/AR488-ESP8266-addon.ino, (https://github.com/Twilight-Logic/AR488/blob/master/src/AR488-ESP8266-addon/AR488-ESP8266-addon.ino,) but the source code says it is version 0.04.10!?
Anyway, I could neither connect to 0.04.10 nor 0.04.11 in AP mode until I un-commented the lineCode: [Select]#define DISABLE_SSL.
Then I could connect but I couldn't switch to client mode, it wouldn't connect.
Any idea what I am doing wrong?
Btw, meanwhile I got some pcbs made, see attachment.
And one more strange find. Remember the odd upload error which I always saw when uploading to my ESP-01? When uploading to my new homemade ESP12F board, the error won't occur. This is absolutely repeatable.
Best regards
Apologies if this seems a silly question, but are you using the https:// prefix rather than http:// to connect?
Hi, I have tested ESP firmware 0.04.11 now successfully, many thanks for the update!
-The admin functions appear not to be implemented yet, right?
-web traffic is always encrypted. There is no online means to switch encryption off right? Only by setting the firmware switch and recompiling can this be done.
-My impression is that with encryption in place switching between tabs on the web page takes noticibly longer, am I just imagining this?
And maybe you can help me on a problem with my new adapter boards:
-I can program my Arduino Pro Micro directly via CDC Serial with the Arduino IDE just fine.
-I can also program the ESP8266 using a CH340C USB to Serial converter with the Arduino IDE.
Now, I would like to program the ESP8266 inside the application, i.e. use the ProMicro as a USB to serial converter and thus replace the CH340 board. I have a simple bridge code for the ProMicro which connects the CDC to the hardware serial, and the ESP does talk to the ProMicro, but the Arduino IDE won't upload the ESP through the ProMicro.
Any idea why this doesn't work?
The data now is routed the following way:
Arduino IDE => COM0COM pair => my port redirector software => ProMicro => ESP8266.
Funny, that the long way works but the direct way connecting the IDE to the ProMicro does not.
It seems to be linked to the CDC handshake emulation.
WaveyDipole - is the ESP32 code available anywhere? I searched through the AR488 github repo but I can't find it. I understand if you feel it's too early to put that out there; OTOH, if it was available as a fork via github you might get other people collaborating on the code side of things. However, I also see that the repo has ~130 contributors, and I'm not even sure if you're the ultimate owner of that project.
I may be in the minority, but I'd much rather have a few network cables going to my instruments than using wifi, so I'm wondering if you have any thoughts on using an ethernet shield rather than wifi. It seems like this wouldn't work with an Uno because the ethernet shields use so many pins -- I'm assuming one would need to use a Mega and move all the "GPIB Stuff" to the higher-numbered pins that it supports. It's something I've thought about trying to do, but I was wondering if you had already had any thoughts on this.
Well, you don't state what steps you are taking to upload or any upload error messages, so its difficult to advise.
Again, you don't provide any code or indication of how your port re-director works
The hardcopy format is correct, the scope sends HPGL and the plotter emulator renders it just fine. The problem is that the line that tells the scope to start sending does not assert when the plotter emulator is set to listen on all addresses. The TDS400 series only support hardcopy in talk-only mode and do not address a plotter at a specific address.
Thanks for confirming that. If you are using talk-only mode, then the receiving interface would need to be in listen-only mode (++mode 0, ++lon 1)? In which case the interface will sit in listening mode with NRFD and NDAC asserted indicating that it is ready to receive data. When characters are transmitted from the instrument in talk-only mode via the GPIB bus it will receive them using the usual three-way handshake process. There is no signal as such to tell the instrument to start sending.
I had a look at what the KE5FX 7470A program is sending to the serial port:
Plotter addressable at 5:Quote++ver
AT488 GPIB-USB version 4.99
++auto
Unrecognized command
++eos 0
++mode 0
++addr 5
++eoi 1
No assigned plotter address:Quote++ver
AT488 GPIB-USB version 4.99
++auto
0
++auto 1
++eos 0
++mode 0
++eoi 1
What is interesting is that, in neither case does the software request a '++read'. In the 'Plotter addressable at 5' instance, the instrument gets addressed (++addr 5) so it is possible that it might automatically send data back to the controller address.
However, in the 'No assigned plotter address' instance, since the instrument is in talk-only mode so cannot be addressed, but the interface is not being set into listen-only (++lon) mode. It is being set into device mode (++mode 0) with ++auto 1 and there appears to be nothing here to trigger the sending of data from the instrument. In device mode without ++lon, the interface will sit idle until addressed by the controller. It does not expect to be communicated with by another device. Maybe the Prologix implementation is different in this respect and receives data from an instrument even when the interface is placed in device mode in a similar fashion to ++lon mode, but then why have a ++lon mode?
I am not sure whether my implementation needs to be adjusted, or whether the HP7470A plotter program needs to handle this differently, but I am willing to work with the author of the KE5FX suite of programs to resolve this.
Incidentally, I noted also that I seem to be randomly getting an 'Unrecognized command' after the '++auto' command is sent. I am not sure why at present but probably down to timing. I will need to investigate this further.
Do you want to try contacting the author of the plotter emulator or would you like me to? I'm more than happy to assist in any way I can, I can test whatever you need with my TDS410A. If we can find anyone who has a real Prologix interface that would make it possible to determine exactly how that works. I suppose another option is to try to pool together several people to buy one for testing purposes, I don't think they're hugely expensive, with 5-10 people it would be a small investment to make the open source interface top notch.
I do have a Prologix interface, but I do not have a Tektronix scope to test it with.
I have found that the Prologix behaves exactly as described in the manual.
I can do simple tests if you tell me what.
Best regards.
I have sent the John Miles an e-mail with a couple of questions and inviting him to pop by this thread.
Hi, John --
I won't be able to check it out for a week or two, the way things are looking as of today (Monday). I'm also unable to put much time into support for third-party adapters (meaning other than Prologix/NI488.2 devices), just because there are so many of them. However, that being said, the truth is that I know very little about the GPIB physical and signaling layers since I've never had to deal with them. Abdul at Prologix would be better-positioned to address a question like that, but then he probably doesn't want to encourage the competition. :)
I will say that yes, that's exactly how device mode works in my understanding -- the instrument takes on the role of bus master/controller. In some cases, the instrument needs to know the adapter's address in order to talk to the emulated 'plotter', and will not work with the adapter configured for listen-only mode. In other cases, the instrument requires that the adapter is in listen-only mode, without an address of its own. This has never made any sense to me either, but empirically that's how it seems to work.
Re: the TDS400 series, sorry, no knowledge of those at all.
(Don't forget that the full source code is there in your installation directory, no need to pore over serial dumps to see what it's doing.)
-- john, KE5FX
I won't be able to check it out for a week or two, the way things are looking as of today (Monday). I'm also unable to put much time into support for third-party adapters (meaning other than Prologix/NI488.2 devices), just because there are so many of them. However, that being said, the truth is that I know very little about the GPIB physical and signaling layers since I've never had to deal with them. Abdul at Prologix would be better-positioned to address a question like that, but then he probably doesn't want to encourage the competition. :)
I will say that yes, that's exactly how device mode works in my understanding -- the instrument takes on the role of bus master/controller. In some cases, the instrument needs to know the adapter's address in order to talk to the emulated 'plotter', and will not work with the adapter configured for listen-only mode. In other cases, the instrument requires that the adapter is in listen-only mode, without an address of its own. This has never made any sense to me either, but empirically that's how it seems to work.
Re: the TDS400 series, sorry, no knowledge of those at all.
(Don't forget that the full source code is there in your installation directory, no need to pore over serial dumps to see what it's doing.)
-- john, KE5FX
I wonder if the best place to start is to connect a real Prologix interface to the plotter emulator and set it to listen for a plot and see if it asserts the line(s) necessary to tell the scope to start sending.
++ver
Prologix GPIB-USB Controller version 6.101
++auto
Unrecognized command
++eos 0
++mode 0
++addr 5
++eoi 1
???++ver
Prologix GPIB-USB Controller version 6.101
++auto
Unrecognized command
++eos 0
++mode 0
++addr 5
++eoi 1
???I have updated my Prologix to firmware 6.107, see attached report.
Screencopy experiments at the end of the report. The successful screencopy was initiated by the7470.exe with Prologix in controller mode.
Have I done anything wrong?
P.S. Just found out that the Prologix answers ++auto with "unrecognized command" when in mode 0 = device mode. Still the same after firmware update.
There is some support for a couple of printer formats in 7470 but it's not well-tested (at least by me) and may not behave as expected.
Well I'm happy to do some regression testing on a build, I have a HP 8594E and a handful of Tek scopes, TDS300, TDS400, TDS700 and TDS3000, all with GPIB. Pretty sure the 3000 only supports printers but I know for sure the 400 supports plotters and the 8594E works perfectly to plot with the current software.
I don't know if it's relevant with the 8593A, but all this talk of "printer addresses" makes me wonder if it's set up for plotter output or printer output. You need to make sure it's set up for plotter output, if there's a choice. There is some support for a couple of printer formats in 7470 but it's not well-tested (at least by me) and may not behave as expected.
The code always sets up ++auto 0 or ++auto 1 based on whether the application calls for device mode or controller mode, but it sends a ++auto query in both cases, as observed above. Arguably I shouldn't be doing that if the adapter is being used in device mode. I'll tweak the GPIB_connect() code to set up auto-read mode only if device_address is valid (i.e., if we're using controller mode). Will also enable ++lon transmission for the listen-only case in device mode, on adapters where the firmware supports it. The only problem is that I'm perilously short on time for regression testing right now...
Hi,
I have repeated the tests with the HP8593E and found that I previously made a stupid mistake. The plotter address was set to 5 but the instrument was configured for printer out. Now, having changed the instrument to plotter out I get encouraging results:
1. Original Prologix adapter + 7470.exe:
Instrument initiated plots work flawlessly now.
2. AR488 USB version 0.48.08 + 7470.exe:
Data is coming in in chunks, the plot builds up, but at the end of plotting 7470.exe crashes with error message "GPIB error, Read Error: 0x2 (communications error)".
On closing the error message window, 7470.exe closes also.
After this, the AR488 is no longer responding, it has to be power-cycled. So, the firmware seems to hang at the end of the received data.
James, just wondering whether you have been able to try my suggestion in post #389, i.e. placing the interface in LON mode manually prior to launching and using the 7470 program? You can do this with the following commands:
++mode 0
++lon 1
I would be interested to know whether that allows the TDS420 to communicate with the interface. If you first connect to the interface with a terminal, then you should see some output without having to enter a ++read command. If that works, then try and connect with the 7470 program with the 'No assigned plotter address' option. There is a possibility that it may take a while or time out as entering commands while in LON mode is a bit slow, but I would be interested in whether it works in principle.
I have repeated the tests with the HP8593E and found that I previously made a stupid mistake. The plotter address was set to 5 but the instrument was configured for printer out. Now, having changed the instrument to plotter out I get encouraging results:
1. Original Prologix adapter + 7470.exe:
Instrument initiated plots work flawlessly now.
++ver
Prologix GPIB-USB Controller version 6.100
++auto
0
++auto 1
++eos 0
++mode 0
++addr 5
++eoi 1
Best regards.
there is a possibility that I messed up and left the AR488_Config file in a state where pin 6 is being used by the SN7516 chipset
OP;
250,279,10250,7479
PU;SP1;LT;;PU;PA80,7096;PD...
++auto 0
++loc
++ver
Prologix ...
Indented traffic is from PC to adapter.Answering my own problem here, just in case someone else bumps into it.
Adding "++read_tmo_ms 25000" gives enough time for the read to complete without timing out.
|O
Hi John,Quotethere is a possibility that I messed up and left the AR488_Config file in a state where pin 6 is being used by the SN7516 chipset
Indeed, you were spot-on.
I have commented out as instructed and now 7470.exe does receive plot data again. But the AR488 firmware still stalls at the end causing 7470.exe to crash, see attached screenshot. After the stall the 32u4 USB CDC port is still present, but no longer answers to commands like ++ver.
I have also attached logged com port traffic. The last ++ver command not being answered seems to cause 7470.exe to fire the error message and abort.
I know it is close to impossible to track this problem down without more detailled information, something I might be able to help with.
I do have a Saleae Logic 16 logic analyzer here, which I can hook up to the GPIB port and I can record a whole sequence. It seems I can also save a measured sequence to a file. The Saleae software appear to be available to the public for free. If you can install the software and import my measurement data, then you could have a direct look at what's going on on my GPIB bus.
Best regards, Tom
Answering my own problem here, just in case someone else bumps into it.
Adding "++read_tmo_ms 25000" gives enough time for the read to complete without timing out.
|O
Glad you figured it out, although I am a little puzzled that it requires a delay quite that long. 100 AC power cycles at 50Hz would take 2 seconds to complete so no more than 2500 - 3000 milliseconds to allow a bit of headroom but I am not familiar with the meter and am not aware as whether there are other factors at play.
I think I need to experiment with the ++eor command as I suspect that readings are being delayed until the ++read_tmo_ms timeout expires. My initial problem was caused by the default timeout being shorter than the reading time, so I set it very high to allow plenty of time for the result to arrive, hoping that when the reply arrived, it would be sent back immediately.
The meter's documentation says nothing about what characters it uses to signify the end of a transmission or whether it uses the EOI line for this.
Interesting first observation: After 7470 sends the OP-coordinates, the Prologix answers a lot quicker (few seconds) than the AR488 (about 10s) with the plot data. May there be a timeout in play?
Pin assignment is shown in the logged traces. Hope you can learn something from my data.
Best regards, Tom
Heh, I noticed that with my TDS460 in plot (HPGL) mode -- it seems to take a few seconds to think, from time to time, and at first I had to issue repeated +read's to get everything. Duh, it was just timing out. :)
Tim
The read_tmo_ms parameter specifies how long to wait for data to arrive so it its timing out then nothing is arriving, but your suspicion could be correct if it is waiting for the preceding command to finish. Out of curiosity, have you allowed for a delay after "*rst" to allow time for the instrument to reboot?
Could I therefore ask whether that delay is consistent or just occasional?It is consistent and happens every time, also loss of contact after having received the plot data happens every time.
File => clear all visible plotsYes, I am using exactly the same procedure.
GPIB => Plotter addressable at 5
Acquire => Wait for device-initiated plot
wait for the RED "Reading data from instrument..." banner to appear
send the plot
wait for the plot to appear
When the AR488 code is waiting for a reply, I assume it is looking for the character(s) or signal specified by ++eor to decide when to send the contents of the buffer back through the serial port. Is that correct? If so, then I'm assuming that the result is already received on the Arduino, but because the terminator hasn't been detected yet, the buffer won't be sent until either the terminator arrives, or the timeout expires.
I'm basing this guess on the fact that my readings appear to be spaced out in read_tmo_ms increments. If my guess is wrong, please let me know!
Hi John,QuoteCould I therefore ask whether that delay is consistent or just occasional?It is consistent and happens every time, also loss of contact after having received the plot data happens every time.
QuoteFile => clear all visible plotsYes, I am using exactly the same procedure.
GPIB => Plotter addressable at 5
Acquire => Wait for device-initiated plot
wait for the RED "Reading data from instrument..." banner to appear
send the plot
wait for the plot to appear
I wonder whether you could send a plot using the Prologix to the 7470 program and save the result to a file?
QuoteI wonder whether you could send a plot using the Prologix to the 7470 program and save the result to a file?
Yes, I can do. What exact data would you like? I can save the 7470.exe output to file. But I have noticed that this is not necessarily what the instrument sends.
The 7470.exe apparently corrects some oddities.
You already have two instrument output examples in the com port PDF logs that I have uploaded earlier, both in ASCII and hex format.
Good enough?
While receiving for a reply from GPIB, characters are not buffered. Characters are sent immediately to the serial port. Detection of the terminator is used only to identify the end of the transmission. Just having another look at "Output data formats" table on page 159 of the 34401 user manual, it would appear that transmission over IEEE488 is terminated with NL only. If the interface is looking for a CR+NL sequence, it won't find one and the timeout period will follow every reading, the result would be that responses to multiple "read?" commands will be spaced out by the timeout period as you describe. It might indeed be worth trying ++eor 2 so that the interface looks for NL only as a terminator.
Thanks for the help Wavey.
I reset the adapter to defaults and then set:
++read_tmo_ms 5000
++eor 2
++eot_char 10
++eot_enable 1
in the setup part of my script.
I now have data coming back from the 34401A at full speed!
:-+
I don't think that ++eot_char and ++eot_enabled should have been necessary as the NL character present in the data stream from the instrument will be passed to serial anyway but I'm glad it worked. That seems to the the second scenario where the custom ++eor command appears to have helped. I will make a note that it may be useful for this instrument.
Thank you for posting that. That must have taken some delicate surgery!Built in temperature sensor is a joke, together with built in voltage reference...
This prompted me to have a look at the datasheet for the 328p and I discovered also that it has a built-in temperature sensor (section 24.8, p 256) via ADC8 so one could possibly also log the temperature of the chip if one wanted.
Since I have observed with my own setup that USB hubs can cause problems, might I ask whether your 32u4 is connected via a USB hub? Have you tried connecting it directly into the PC? It seems unlikely given that the Prologix works, but just want to rule it out. BTW, are you still using the HC06 to wirelessly connect the Arduino to the PC, or is it directly connected via USB cable?
Thank you for posting that. That must have taken some delicate surgery!Built in temperature sensor is a joke, together with built in voltage reference...
This prompted me to have a look at the datasheet for the 328p and I discovered also that it has a built-in temperature sensor (section 24.8, p 256) via ADC8 so one could possibly also log the temperature of the chip if one wanted.
You can use built in temp sensor to look at gross trends but not much more than that.
External temp sensors ar not that expensive..
To make sure the issue is not related to the USB CDC port, I switched over to using the Leonardo hardware serial port (RXO, TXI lines) instead and hooked it up to a CH340 USB to serial converter, also directly plugged into the PC.
The behavior is exactly the same as with CDC. Host initiated plots transfer just fine. Instrument initiated plots initially start with the already discussed delay of about 10s and when the transfer is complete, the AR488 no longer reacts to commands like ++ver and 7470.exe crashes. Disconnecting from the GPIB bus is not enough to recover communication, only a power cycle will do the job.
So, this appears to be not some kind of "dirt effect" but a real firmware problem.
Can you think of any more test I can do and any more data I can gather to help you fix this?
Anything to be learned from AR488 debug output? Is it possible to run in over the CDC USB port but log the debug output over the hardware port to keep the streams separated and avoid debug data to interfere with normal operation?
Best regards.
Is it possible to run in over the CDC USB port but log the debug output over the hardware port to keep the streams separated and avoid debug data to interfere with normal operation?
Hi John,
I have started playing with your ESP8266 firmware again and I'm having troubles:
0.04.06 which does not have SSL yet works fine in both AP and Client mode.
0.04.11 with SSL works well in AP mode (have tested this before, now I know I have to enter https:// :-) ), but when I switch it to Client mode it won't connect to my home AP, but fall back to AP mode.
Any hints or any test I can do?
Best regards, Tom
#ifndef DISABLE_SSL
configTime(3 * 3600, 0, "pool.ntp.org", "time.nist.gov");
#endif
Following on from that, I would like to confirm that you ran the Prologix GPIB Configurator (prologix.exe) supplied with the KE5FX tools and whether it detected the AR488 interface?
Also, after successful detection, did you click the 'Update CONNECT.INI' button to save the detected settings (or else manually edited the file via 'Edit CONNECT.INI')? I think you said this worked OK with the Prologix so you may have done this at least once, but since the Prologix and AR488 would present on different COM ports, the CONNECT.INI would need updating each time the interfaces are swapped or you wanted to switch between them. Apologies if you have already provided this info although I couldn't see it while scanning back through the discussion. I'm still not ruling out a firmware problem, but would like to eliminate the possibility that the 7470.exe program is not communicating with the intended serial port from the equation.
Btw, is the AR488 com port interrupt driven or is it polled in the main loop?
1. In version 0.4.11, comment out the following section (lines 847 - 849):
I did update connect.ini. This is not the issue. 7470.exe DOES receive plot data from the AR488 and display it, but at the end of an instrument initiated plot, the AR488 apparently gets into an endless loop where it no longer responds to COM commands and thus 7470.exe terminates with an error message. By looking at debug messages it should be possible to find out in which part of the firmware code the AR488 gets stuck. What should I look out for?
Btw, is the AR488 com port interrupt driven or is it polled in the main loop?
Hi John,Quote1. In version 0.4.11, comment out the following section (lines 847 - 849):
This has indeed helped, many thanks. Now, I get a stable connection in client mode, both with dynamic and static IP.
Is the time server causing trouble by responding too slowly?
Maybe a software switch to disable this feature would be useful.
Best regards,
Tom
I would suggest enabling DEBUG7 and I would be looking at whether the loop stops as indicated by an 'After loop' output and the value of tranBrk.I have just tried this. The idea was to mimic what 7470.exe is doing manually via a terminal program.
++ver
Prologix GPIB-USB Controller version 6.100
++auto
0
++auto 1
++eos 0
++mode 0
++addr 5
++eoi 1
Start listen ->
TRNb: 0
rEOI: 0
ATN: HIGH
4F 50 3B D A After loop:
TRNb: 0
ATN: 0
<- End listen.
250,279,10250,7479
++ver
Here is the logged com port traffic:Code: [Select]++ver
Prologix GPIB-USB Controller version 6.100
++auto
0
++auto 1
++eos 0
++mode 0
++addr 5
++eoi 1
Start listen ->
TRNb: 0
rEOI: 0
ATN: HIGH
4F 50 3B D A After loop:
TRNb: 0
ATN: 0
<- End listen.
250,279,10250,7479
++ver
Note that after me entering the plot coordinates "250,279,10250,7479" the instrument should send the plot data which it doesn't with DEBUG7.
No answer from the AR488 to my ++ver at the end.
Best regards,
Tom
Hi John,
many thanks for the new version.
Congratulations, you were spot on!
Now, instrument initiated plots from my HP8593E work flawlessly!
And plot data is coming a lot quicker than before! :-+
Many thanks again for your great work and best regards, Tom
Nice, I must give this a try. Between work and the whole Covid mess I got sidetracked and have not had a chance to mess with this lately.
Thanks for all the work you guys are putting into this project. Since this thread started with just a couple of the full size uno and mega boards and has now evolved into multiple variants of micro, mini, esp, rasberry, etc... is there a simple way of adding a document on the github or on 1st page of topic with maybe excel tables with which version arduino, wifi/bluetooth/ethernet support/ and maybe verified equipment that has been tested working. Bonus points for rounding up different pcb adapter links that have been used so there could be easier way to have someone like myself say well I have a few V3 nanos but want bluetooth connectivity to x multimeter and x o-scope. Would be cool to see what members have already tested sucessfully and would let those thinking about building up the ar488 see if a different version board would be a better option. If this sounds like it should be on a seperate forum topic please chime in.
| MCU | Board | Serial Ports | Layouts |
| 328p | Uno R3 | Single UART shared with USB | Layout as per original project by Emanuelle Girlando |
| 328p | Nano | USB/Single UART shared with USB | Identical to Uno |
| 32u4 | Micro | USB/CDC+1 UART | Compact layout by Artag, designed for his back-of-IEEE488-plug adapter board |
| 32u4 | Leonardo R3 | USB/CDC+1 UART | Identical to UNO |
| 2560 | Mega 2560 | 4 x UART, Serial0 shared with USB | D - default using pins to either side of board E1 using first row of end connector E2 - using second row of end connector |
| ESP32 | Various | 3 x UART, U0UXD/Serial0 shared with USB | In development |
I haven't had a chance to try the TDS400 but I had to do something with a TDS700 already so I tried plotting from it. I can confirm that once I sent a ++lon and then loaded up the plotter emulator I was able to hit Hardcopy and it plots perfectly.
So do we know at this point whether the need to send ++lon is a bug in the GPIB interface or in the 7470A emulator?
Got it working with a Fluke 8840a :)
I'm not sure that the need to send ++lon should be characterised as a bug. It simply places the interface in the required operating mode. Looking at the manual, the TDS-700, like the TDS-400, operates in non-addressed or talk-only mode. In order to receive, the "plotter" would need to be in the corresponding non-addressed listen-only mode. This is what the ++lon command does. This kind of direct point-to-point communication makes sense in a 1:1 scenario where you have a plotter connected directly to the back of an instrument with the instrument pushing data over the GPIB wires to the plotter.
Got it working with a Fluke 8840a :)
Sorry for missing your earlier comment and thank you for posting your photos. Interesting to see different instruments being connected. Curious that you didn't use an IEEE488 connector but soldered directly to the board inside the instrument. Are you intending to mount this internally somehow? I haven't tried those Elegoo boards so its good to see that they do also work.
The interface is connected to my Solartron 7061 which performs logging using PuTTy or the arduino serial monitor
I am trying to read out the memory of the 7061. I can do this 1 memory location at a time but to do this automatically has exceeded my skill level :-)
For example:
Using the serial monitor (red is my typed command)
DU is the 7061 command to DUmp the memory contents
HIST is the memory location of the particular measurement being read back.
Hello from AR_SERIAL :-)
++Auto 2
++Read
-0.0000101 VDC CHAN 0
DU
++Read
-0.0000129 VDC CHAN 0 HIST 1
++Read
-0.0000133 VDC CHAN 0 HIST 2
++Read
-0.0000134 VDC CHAN 0 HIST 3
etc
Using this macro
#define MACRO_4 "\
++addr 1\n\
DU\
++auto 3\n\
++read\
returns -0.0000042 VDC CHAN 0 HIST 3 and Bad Argument on the meter
and using this modified macro
#define MACRO_4 "\
++addr 1\n\
DU\
++auto 2\n\
++read\
returns -0.0000054 VDC CHAN 0 HIST 2
Possibly a timing issue, but I'm now a bit stuck, any help greatly appreciated.
Dek
<edit>
If I reorder the macro to
++auto
DU
++Read
then it works ;D ;D ;D
Also works if i enter the commands manually in that order via the serial monitor or PuTTy :-+
Hello from AR_SERIAL :-)
#define MACRO_4 "\
++addr 1\n\
DU\n\
++auto 3\n\
++read\
"#define MACRO_4 "\
++addr 1\n\
DU\n\
++auto 2\n\
++read\
"I have used the AR488 controller on Arduino Nano to talk to many different devices without any problem. But one recently stumped me. Its a Cryocon temperature controller that uses EOI but no EOS characters. I have set the program for ++eoi 1 and ++eos 3 and it still didn't work. The device would switch to remote and then go back to local with ++loc command, so it was getting something. I also verified that EOI line was indeed asserted during the transmission. Crycon worked just fine with NI controller and VISA. Not sure what the problem was, has anyone used an instrument with these settings?
If anyone wants to copy the version I built, you can get PCBs from here : https://oshpark.com/shared_projects/HrS1HLSE
I will probably revise that at some point (I'd like to move the daughterboard further along, making the USB connector stick out less) but don't know how long I'll take to get around to that. The electrical connections will stay the same so the software will still work.
You use the serial port to select the instrument. You can set all the GPIB addresses the same as there is only one on each bus.
Side question, is it still possible to have multiple devices (with unique addresses) on the same gpib bus with one ar488?
Well it's a bug in one part or another, Hardcopy works just fine IF you first load up another program and issue the required command. It's looking to me like it's a bug in the plotter emulator, it should be sending ++lon if you set it to non-addressed mode and then have it listen for a device initiated plot.
If the option to send ++lon is added then I believe that will fix it.
00004349 2020-05-29 14:45:58,5908227 +127,2577056 IRP_MJ_CREATE - process 5936 () DOWN 0x00000000
00004350 2020-05-29 14:45:58,5961393 +0,0053166 IRP_MJ_CREATE UP 0x00000000
00004351 2020-05-29 14:45:58,5962220 +0,0000827 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00004352 2020-05-29 14:45:58,5962281 +0,0000061 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00004371 2020-05-29 14:45:58,5964757 +0,0000065 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00004372 2020-05-29 14:45:58,5964785 +0,0000028 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00004373 2020-05-29 14:45:58,5964838 +0,0000053 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00004374 2020-05-29 14:45:58,5964863 +0,0000025 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00004375 2020-05-29 14:45:58,5964910 +0,0000047 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00004376 2020-05-29 14:45:58,5964941 +0,0000031 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00004377 2020-05-29 14:45:58,5964983 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00004378 2020-05-29 14:45:58,5965008 +0,0000025 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00004379 2020-05-29 14:45:58,5965050 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 09 00 00 00 80 00 00 80 36 43 00 00 36 43 00 00 ........6C..6C..
00004380 2020-05-29 14:45:58,5981180 +0,0016130 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00004381 2020-05-29 14:45:58,5981281 +0,0000101 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS DOWN 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00004382 2020-05-29 14:45:58,5981309 +0,0000028 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS UP 0x00000000
00004401 2020-05-29 14:45:58,5982019 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00004402 2020-05-29 14:45:58,5982046 +0,0000027 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00004403 2020-05-29 14:45:58,5982100 +0,0000054 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS DOWN 0x00000000
00004404 2020-05-29 14:45:58,5982125 +0,0000025 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS UP 0xc0000023
00004405 2020-05-29 14:45:58,5982197 +0,0000072 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00004406 2020-05-29 14:45:58,5982220 +0,0000023 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00004407 2020-05-29 14:45:58,5982267 +0,0000047 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00004408 2020-05-29 14:45:58,5982295 +0,0000028 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00004409 2020-05-29 14:45:58,5982334 +0,0000039 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00004410 2020-05-29 14:45:58,5982357 +0,0000023 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00004411 2020-05-29 14:45:58,5982396 +0,0000039 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 01 00 00 00 40 00 00 80 36 43 00 00 36 43 00 00 ....@...6C..6C..
00004412 2020-05-29 14:45:58,6001203 +0,0018807 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00004413 2020-05-29 14:45:58,6809154 +0,0807951 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 76 65 72 0d 0a ++ver..
00004416 2020-05-29 14:45:58,7356431 +0,0000101 IRP_MJ_READ UP 0x00000000 41 A
00004418 2020-05-29 14:45:58,7356582 +0,0000028 IRP_MJ_READ UP 0x00000000 52 R
00004420 2020-05-29 14:45:58,7356654 +0,0000025 IRP_MJ_READ UP 0x00000000 34 4
00004422 2020-05-29 14:45:58,7356724 +0,0000025 IRP_MJ_READ UP 0x00000000 38 8
00004424 2020-05-29 14:45:58,7356791 +0,0000025 IRP_MJ_READ UP 0x00000000 38 8
00004426 2020-05-29 14:45:58,7356858 +0,0000025 IRP_MJ_READ UP 0x00000000 20
00004428 2020-05-29 14:45:58,7356925 +0,0000025 IRP_MJ_READ UP 0x00000000 47 G
00004430 2020-05-29 14:45:58,7356992 +0,0000025 IRP_MJ_READ UP 0x00000000 50 P
00004432 2020-05-29 14:45:58,7357062 +0,0000028 IRP_MJ_READ UP 0x00000000 49 I
00004434 2020-05-29 14:45:58,7357129 +0,0000028 IRP_MJ_READ UP 0x00000000 42 B
00004436 2020-05-29 14:45:58,7357193 +0,0000025 IRP_MJ_READ UP 0x00000000 2d -
00004438 2020-05-29 14:45:58,7357260 +0,0000025 IRP_MJ_READ UP 0x00000000 55 U
00004440 2020-05-29 14:45:58,7357420 +0,0000118 IRP_MJ_READ UP 0x00000000 53 S
00004442 2020-05-29 14:45:58,7357492 +0,0000028 IRP_MJ_READ UP 0x00000000 42 B
00004444 2020-05-29 14:45:58,7357568 +0,0000034 IRP_MJ_READ UP 0x00000000 20
00004446 2020-05-29 14:45:58,7357643 +0,0000028 IRP_MJ_READ UP 0x00000000 2c ,
00004448 2020-05-29 14:45:58,7357716 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00004450 2020-05-29 14:45:58,7357794 +0,0000036 IRP_MJ_READ UP 0x00000000 76 v
00004452 2020-05-29 14:45:58,7357872 +0,0000031 IRP_MJ_READ UP 0x00000000 65 e
00004454 2020-05-29 14:45:58,7357950 +0,0000030 IRP_MJ_READ UP 0x00000000 72 r
00004456 2020-05-29 14:45:58,7358029 +0,0000031 IRP_MJ_READ UP 0x00000000 73 s
00004458 2020-05-29 14:45:58,7358096 +0,0000025 IRP_MJ_READ UP 0x00000000 69 i
00004460 2020-05-29 14:45:58,7358166 +0,0000026 IRP_MJ_READ UP 0x00000000 6f o
00004462 2020-05-29 14:45:58,7358233 +0,0000026 IRP_MJ_READ UP 0x00000000 6e n
00004464 2020-05-29 14:45:58,7358300 +0,0000026 IRP_MJ_READ UP 0x00000000 20
00004466 2020-05-29 14:45:58,7358367 +0,0000025 IRP_MJ_READ UP 0x00000000 35 5
00004468 2020-05-29 14:45:58,7358436 +0,0000027 IRP_MJ_READ UP 0x00000000 2e .
00004470 2020-05-29 14:45:58,7358504 +0,0000028 IRP_MJ_READ UP 0x00000000 30 0
00004472 2020-05-29 14:45:58,7358571 +0,0000026 IRP_MJ_READ UP 0x00000000 20
00004474 2020-05-29 14:45:58,7358638 +0,0000026 IRP_MJ_READ UP 0x00000000 23 #
00004476 2020-05-29 14:45:58,7358705 +0,0000025 IRP_MJ_READ UP 0x00000000 31 1
00004478 2020-05-29 14:45:58,7358772 +0,0000025 IRP_MJ_READ UP 0x00000000 20
00004480 2020-05-29 14:45:58,7358842 +0,0000028 IRP_MJ_READ UP 0x00000000 30 0
00004482 2020-05-29 14:45:58,7358909 +0,0000026 IRP_MJ_READ UP 0x00000000 2e .
00004484 2020-05-29 14:45:58,7358976 +0,0000025 IRP_MJ_READ UP 0x00000000 34 4
00004486 2020-05-29 14:45:58,7359043 +0,0000025 IRP_MJ_READ UP 0x00000000 38 8
00004488 2020-05-29 14:45:58,7359110 +0,0000025 IRP_MJ_READ UP 0x00000000 2e .
00004490 2020-05-29 14:45:58,7359180 +0,0000028 IRP_MJ_READ UP 0x00000000 32 2
00004492 2020-05-29 14:45:58,7359247 +0,0000025 IRP_MJ_READ UP 0x00000000 34 4
00004494 2020-05-29 14:45:58,7359314 +0,0000025 IRP_MJ_READ UP 0x00000000 0d .
00004496 2020-05-29 14:45:58,7359384 +0,0000028 IRP_MJ_READ UP 0x00000000 0a .
00004497 2020-05-29 14:45:58,7903279 +0,0543895 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 73 20 30 0d 0a ++eos 0..
00004499 2020-05-29 14:45:58,8996860 +0,1084811 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6d 6f 64 65 20 30 0d 0a ++mode 0..
00004502 2020-05-29 14:45:59,2043744 +0,2500027 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004503 2020-05-29 14:45:59,2043867 +0,0000123 IRP_MJ_READ UP 0xc0000120
00004504 2020-05-29 14:45:59,2043948 +0,0000081 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004505 2020-05-29 14:45:59,2590512 +0,0546564 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 69 20 31 0d 0a ++eoi 1..
00004508 2020-05-29 14:46:00,3372438 +0,9975756 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004509 2020-05-29 14:46:00,3372564 +0,0000126 IRP_MJ_READ UP 0xc0000120
00004510 2020-05-29 14:46:00,3372648 +0,0000084 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004512 2020-05-29 14:46:01,3570307 +0,9979429 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004513 2020-05-29 14:46:01,3570433 +0,0000126 IRP_MJ_READ UP 0xc0000120
00004514 2020-05-29 14:46:01,3570528 +0,0000095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004516 2020-05-29 14:46:02,3805158 +0,9980992 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004517 2020-05-29 14:46:02,3805312 +0,0000154 IRP_MJ_READ UP 0xc0000120
00004518 2020-05-29 14:46:02,3805399 +0,0000087 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004520 2020-05-29 14:46:03,4040105 +0,9978760 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004521 2020-05-29 14:46:03,4040230 +0,0000125 IRP_MJ_READ UP 0xc0000120
00004522 2020-05-29 14:46:03,4040353 +0,0000123 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004524 2020-05-29 14:46:04,4274981 +0,9975095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004525 2020-05-29 14:46:04,4275095 +0,0000114 IRP_MJ_READ UP 0xc0000120
00004526 2020-05-29 14:46:04,4275179 +0,0000084 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004528 2020-05-29 14:46:05,4509938 +0,9980992 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004529 2020-05-29 14:46:05,4510058 +0,0000120 IRP_MJ_READ UP 0xc0000120
00004530 2020-05-29 14:46:05,4510153 +0,0000095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004532 2020-05-29 14:46:06,4744719 +0,9959925 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004533 2020-05-29 14:46:06,4744837 +0,0000118 IRP_MJ_READ UP 0xc0000120
00004534 2020-05-29 14:46:06,4744906 +0,0000069 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004536 2020-05-29 14:46:07,4979735 +0,9975472 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004537 2020-05-29 14:46:07,4979880 +0,0000145 IRP_MJ_READ UP 0xc0000120
00004538 2020-05-29 14:46:07,4979967 +0,0000087 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004540 2020-05-29 14:46:08,5214514 +0,9979688 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004541 2020-05-29 14:46:08,5214678 +0,0000164 IRP_MJ_READ UP 0xc0000120
00004542 2020-05-29 14:46:08,5214771 +0,0000093 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004544 2020-05-29 14:46:09,5449443 +0,9979880 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004545 2020-05-29 14:46:09,5449563 +0,0000120 IRP_MJ_READ UP 0xc0000120
00004546 2020-05-29 14:46:09,5449694 +0,0000131 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004548 2020-05-29 14:46:10,5840674 +0,9931751 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004549 2020-05-29 14:46:10,5840817 +0,0000143 IRP_MJ_READ UP 0xc0000120
00004550 2020-05-29 14:46:10,5840937 +0,0000120 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004552 2020-05-29 14:46:11,6075447 +0,9981115 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004553 2020-05-29 14:46:11,6075576 +0,0000129 IRP_MJ_READ UP 0xc0000120
00004554 2020-05-29 14:46:11,6075684 +0,0000108 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004556 2020-05-29 14:46:12,1153852 +0,4997333 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004557 2020-05-29 14:46:12,1154101 +0,0000249 IRP_MJ_READ UP 0xc0000120
00004558 2020-05-29 14:46:12,1154224 +0,0000123 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004559 2020-05-29 14:46:12,1700698 +0,0546474 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6c 6f 63 0d 0a ++loc..
00004562 2020-05-29 14:46:12,2247743 +0,0000129 IRP_MJ_READ UP 0x00000000 55 U
00004564 2020-05-29 14:46:12,2247849 +0,0000025 IRP_MJ_READ UP 0x00000000 6e n
00004566 2020-05-29 14:46:12,2247921 +0,0000025 IRP_MJ_READ UP 0x00000000 72 r
00004568 2020-05-29 14:46:12,2247989 +0,0000026 IRP_MJ_READ UP 0x00000000 65 e
00004570 2020-05-29 14:46:12,2248056 +0,0000026 IRP_MJ_READ UP 0x00000000 63 c
00004572 2020-05-29 14:46:12,2248125 +0,0000025 IRP_MJ_READ UP 0x00000000 6f o
00004574 2020-05-29 14:46:12,2248195 +0,0000028 IRP_MJ_READ UP 0x00000000 67 g
00004576 2020-05-29 14:46:12,2248262 +0,0000025 IRP_MJ_READ UP 0x00000000 6e n
00004578 2020-05-29 14:46:12,2248329 +0,0000025 IRP_MJ_READ UP 0x00000000 69 i
00004580 2020-05-29 14:46:12,2248396 +0,0000025 IRP_MJ_READ UP 0x00000000 7a z
00004582 2020-05-29 14:46:12,2248466 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00004584 2020-05-29 14:46:12,2248533 +0,0000028 IRP_MJ_READ UP 0x00000000 64 d
00004586 2020-05-29 14:46:12,2248600 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00004588 2020-05-29 14:46:12,2248667 +0,0000025 IRP_MJ_READ UP 0x00000000 63 c
00004590 2020-05-29 14:46:12,2248734 +0,0000025 IRP_MJ_READ UP 0x00000000 6f o
00004592 2020-05-29 14:46:12,2248801 +0,0000025 IRP_MJ_READ UP 0x00000000 6d m
00004594 2020-05-29 14:46:12,2248869 +0,0000026 IRP_MJ_READ UP 0x00000000 6d m
00004596 2020-05-29 14:46:12,2248936 +0,0000026 IRP_MJ_READ UP 0x00000000 61 a
00004598 2020-05-29 14:46:12,2249003 +0,0000026 IRP_MJ_READ UP 0x00000000 6e n
00004600 2020-05-29 14:46:12,2249072 +0,0000027 IRP_MJ_READ UP 0x00000000 64 d
00004602 2020-05-29 14:46:12,2249139 +0,0000027 IRP_MJ_READ UP 0x00000000 0d .
00004604 2020-05-29 14:46:12,2249207 +0,0000026 IRP_MJ_READ UP 0x00000000 0a .
00004606 2020-05-29 14:46:12,4747722 +0,2498474 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004607 2020-05-29 14:46:12,4747910 +0,0000188 IRP_MJ_READ UP 0xc0000120
00004608 2020-05-29 14:46:12,4747993 +0,0000083 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004610 2020-05-29 14:46:12,9747897 +0,4999728 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00004611 2020-05-29 14:46:12,9748012 +0,0000115 IRP_MJ_READ UP 0xc0000120
00004612 2020-05-29 14:46:12,9748104 +0,0000092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00004613 2020-05-29 14:46:12,9748238 +0,0000134 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR DOWN 0x00000000
00004614 2020-05-29 14:46:12,9754549 +0,0006311 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR UP 0x00000000
00004615 2020-05-29 14:46:12,9754694 +0,0000145 IRP_MJ_CLOSE DOWN 0x00000000
00004616 2020-05-29 14:46:12,9774188 +0,0019494 IRP_MJ_CLOSE UP 0x00000000
00004617 2020-05-29 14:47:37,6668899 +84,6975801 IRP_MJ_CREATE - process 2568 (putty.exe) DOWN 0x00000000
00004618 2020-05-29 14:47:37,6723356 +0,0054457 IRP_MJ_CREATE UP 0x00000000
00004635 2020-05-29 14:47:37,6724541 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00004636 2020-05-29 14:47:37,6724571 +0,0000030 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00004637 2020-05-29 14:47:37,6724700 +0,0000129 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS DOWN 0x00000000
00004638 2020-05-29 14:47:37,6724728 +0,0000028 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS UP 0x00000000
00004639 2020-05-29 14:47:37,6724781 +0,0000053 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00004640 2020-05-29 14:47:37,6724806 +0,0000025 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00004641 2020-05-29 14:47:37,6724848 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00004642 2020-05-29 14:47:37,6724881 +0,0000033 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00004643 2020-05-29 14:47:37,6724923 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00004644 2020-05-29 14:47:37,6724948 +0,0000025 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00004645 2020-05-29 14:47:37,6724990 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 01 00 00 00 40 00 00 00 6c 86 00 00 9b 21 00 00 ....@...l....!..
00004646 2020-05-29 14:47:37,6743420 +0,0018430 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00004647 2020-05-29 14:47:37,6743496 +0,0000076 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS DOWN 0x00000000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00004648 2020-05-29 14:47:37,6743526 +0,0000030 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS UP 0x00000000
00004650 2020-05-29 14:47:42,2104258 +4,5358159 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6c 6f 63 ++loc
00004652 2020-05-29 14:47:42,2114119 +0,0000388 IRP_MJ_WRITE DOWN 0x00000000 0d .
00004654 2020-05-29 14:47:42,2153306 +0,0029895 IRP_MJ_READ UP 0x00000000 55 U
00004656 2020-05-29 14:47:42,2153717 +0,0000065 IRP_MJ_READ UP 0x00000000 6e n
00004658 2020-05-29 14:47:42,2153923 +0,0000030 IRP_MJ_READ UP 0x00000000 72 r
00004660 2020-05-29 14:47:42,2154122 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00004662 2020-05-29 14:47:42,2154314 +0,0000027 IRP_MJ_READ UP 0x00000000 63 c
00004664 2020-05-29 14:47:42,2154504 +0,0000025 IRP_MJ_READ UP 0x00000000 6f o
00004666 2020-05-29 14:47:42,2154694 +0,0000028 IRP_MJ_READ UP 0x00000000 67 g
00004668 2020-05-29 14:47:42,2154887 +0,0000028 IRP_MJ_READ UP 0x00000000 6e n
00004670 2020-05-29 14:47:42,2155074 +0,0000025 IRP_MJ_READ UP 0x00000000 69 i
00004672 2020-05-29 14:47:42,2155262 +0,0000026 IRP_MJ_READ UP 0x00000000 7a z
00004674 2020-05-29 14:47:42,2155454 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00004676 2020-05-29 14:47:42,2155644 +0,0000025 IRP_MJ_READ UP 0x00000000 64 d
00004678 2020-05-29 14:47:42,2155834 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00004680 2020-05-29 14:47:42,2156024 +0,0000028 IRP_MJ_READ UP 0x00000000 63 c
00004682 2020-05-29 14:47:42,2156217 +0,0000028 IRP_MJ_READ UP 0x00000000 6f o
00004684 2020-05-29 14:47:42,2156404 +0,0000025 IRP_MJ_READ UP 0x00000000 6d m
00004686 2020-05-29 14:47:42,2156594 +0,0000025 IRP_MJ_READ UP 0x00000000 6d m
00004688 2020-05-29 14:47:42,2156784 +0,0000028 IRP_MJ_READ UP 0x00000000 61 a
00004690 2020-05-29 14:47:42,2156971 +0,0000028 IRP_MJ_READ UP 0x00000000 6e n
00004692 2020-05-29 14:47:42,2157158 +0,0000028 IRP_MJ_READ UP 0x00000000 64 d
00004694 2020-05-29 14:47:42,2157346 +0,0000026 IRP_MJ_READ UP 0x00000000 0d .
00004696 2020-05-29 14:47:42,2157538 +0,0000028 IRP_MJ_READ UP 0x00000000 0a .
00004698 2020-05-29 14:47:49,1101189 +6,8943489 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6d 6f 64 65 ++mode
00004700 2020-05-29 14:47:49,1104187 +0,0000422 IRP_MJ_WRITE DOWN 0x00000000 0d .
00004702 2020-05-29 14:47:49,1133322 +0,0019905 IRP_MJ_READ UP 0x00000000 30 0
00004704 2020-05-29 14:47:49,1133729 +0,0000067 IRP_MJ_READ UP 0x00000000 0d .
00004706 2020-05-29 14:47:49,1133942 +0,0000031 IRP_MJ_READ UP 0x00000000 0a .
00004708 2020-05-29 14:47:53,5701226 +4,4567119 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6d 6f 64 65 20 31 ++mode 1
00004710 2020-05-29 14:47:53,5704246 +0,0000413 IRP_MJ_WRITE DOWN 0x00000000 0d .
00004712 2020-05-29 14:47:57,8221312 +4,2507878 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6c 6f 63 ++loc
00004714 2020-05-29 14:47:57,8224304 +0,0000391 IRP_MJ_WRITE DOWN 0x00000000 0d .
Back on 18th March in post #397 KE5FX did say he would add that feature. On his website I can see that the toolset was updated on 20th March (v1980) and again on the 26th March (v1981). I downloaded it to have a look, but could not see the ++lon feature implemented it yet so we will have to wait until the next release I think.
enable_LON 1Incomprehensibility detected.
GPIB Toolkit version 1.981 , released March 26, 2020.
When you start the HP 7470A Emulator ver 2.05, it sets the mode
++eos 0
++mode 0
++eoi 1
Next, when you press the key 'w' command is sent
++loc
in 'device' mode, it is naturally not supported :(
Where is the mistake? :-//
Artag,
many thanks for your explanation. forget about the pin1-pin4, I have included another photo, is it the correct way to solder the GPIB connector?
Hi, I am running AR488 on an UNO with a shield carrying a 75160/1 and it seems to work OK into my TEK744A on address 7. I am issuing commands via a terminal emulator att 115200baud. eg if I issue the following :-
++mode 1
++addr 7
++auto 1
*idn?
it correctly prints the scope's ID string.
However, I cannot get the HP7470A emulator to work with the 744A ... the emulator displays a red banner saying receiving data but when I press the hardcopy button on the scope the count stays at 0.
The scope s set for GPIB, address 7, "hardcopy only" mode and the emulator is set for "listen-only" and "wait for device initiated print".
What am I doing wrong? |O
TIA
Dave
As far as I can tell the AR488 is working OK since I can access the scope and dump the screen via a terminal emulator.
Not a great day :-(
00001347 2020-06-29 17:36:42,9660941 +13,6866627 IRP_MJ_CREATE - process 44368 (7470.exe) DOWN 0x00000000
00001348 2020-06-29 17:36:42,9812575 +0,0151634 IRP_MJ_CREATE UP 0x00000000
00001349 2020-06-29 17:36:42,9813058 +0,0000483 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00001350 2020-06-29 17:36:42,9822685 +0,0009627 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00001369 2020-06-29 17:36:42,9824903 +0,0000061 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00001370 2020-06-29 17:36:42,9832625 +0,0007722 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00001371 2020-06-29 17:36:42,9832874 +0,0000249 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00001372 2020-06-29 17:36:42,9842758 +0,0009884 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00001373 2020-06-29 17:36:42,9843017 +0,0000259 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00001374 2020-06-29 17:36:42,9852619 +0,0009602 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00001375 2020-06-29 17:36:42,9852725 +0,0000106 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00001376 2020-06-29 17:36:42,9852770 +0,0000045 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00001377 2020-06-29 17:36:42,9852815 +0,0000045 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 09 00 00 00 80 00 00 00 00 04 00 00 00 04 00 00 ................
00001378 2020-06-29 17:36:42,9872577 +0,0019762 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00001379 2020-06-29 17:36:42,9872801 +0,0000224 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS DOWN 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00001380 2020-06-29 17:36:42,9872840 +0,0000039 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS UP 0x00000000
00001399 2020-06-29 17:36:42,9873597 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00001400 2020-06-29 17:36:42,9882528 +0,0008931 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00001401 2020-06-29 17:36:42,9882603 +0,0000075 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS DOWN 0x00000000
00001402 2020-06-29 17:36:42,9882634 +0,0000031 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS UP 0xc000000d
00001403 2020-06-29 17:36:42,9882710 +0,0000076 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00001404 2020-06-29 17:36:42,9892532 +0,0009822 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00001405 2020-06-29 17:36:42,9892596 +0,0000064 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00001406 2020-06-29 17:36:42,9902721 +0,0010125 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00001407 2020-06-29 17:36:42,9902779 +0,0000058 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00001408 2020-06-29 17:36:42,9902810 +0,0000031 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00001409 2020-06-29 17:36:42,9902849 +0,0000039 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 01 00 00 00 40 00 00 00 00 04 00 00 00 04 00 00 ....@...........
00001410 2020-06-29 17:36:42,9922502 +0,0019653 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00001411 2020-06-29 17:36:43,0682197 +0,0759695 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 76 65 72 0d 0a ++ver..
00001414 2020-06-29 17:36:43,1199939 +0,0000154 IRP_MJ_READ UP 0x00000000 41 A
00001416 2020-06-29 17:36:43,1200042 +0,0000034 IRP_MJ_READ UP 0x00000000 52 R
00001418 2020-06-29 17:36:43,1200115 +0,0000031 IRP_MJ_READ UP 0x00000000 34 4
00001420 2020-06-29 17:36:43,1200184 +0,0000028 IRP_MJ_READ UP 0x00000000 38 8
00001422 2020-06-29 17:36:43,1200254 +0,0000031 IRP_MJ_READ UP 0x00000000 38 8
00001424 2020-06-29 17:36:43,1200324 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00001426 2020-06-29 17:36:43,1200394 +0,0000031 IRP_MJ_READ UP 0x00000000 47 G
00001428 2020-06-29 17:36:43,1200467 +0,0000031 IRP_MJ_READ UP 0x00000000 50 P
00001430 2020-06-29 17:36:43,1200536 +0,0000030 IRP_MJ_READ UP 0x00000000 49 I
00001432 2020-06-29 17:36:43,1200606 +0,0000031 IRP_MJ_READ UP 0x00000000 42 B
00001434 2020-06-29 17:36:43,1200676 +0,0000031 IRP_MJ_READ UP 0x00000000 2d -
00001436 2020-06-29 17:36:43,1200746 +0,0000034 IRP_MJ_READ UP 0x00000000 55 U
00001438 2020-06-29 17:36:43,1200816 +0,0000031 IRP_MJ_READ UP 0x00000000 53 S
00001440 2020-06-29 17:36:43,1200886 +0,0000031 IRP_MJ_READ UP 0x00000000 42 B
00001442 2020-06-29 17:36:43,1200955 +0,0000030 IRP_MJ_READ UP 0x00000000 20
00001444 2020-06-29 17:36:43,1201025 +0,0000030 IRP_MJ_READ UP 0x00000000 2c ,
00001446 2020-06-29 17:36:43,1201092 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00001448 2020-06-29 17:36:43,1201162 +0,0000031 IRP_MJ_READ UP 0x00000000 76 v
00001450 2020-06-29 17:36:43,1201235 +0,0000034 IRP_MJ_READ UP 0x00000000 65 e
00001452 2020-06-29 17:36:43,1201302 +0,0000031 IRP_MJ_READ UP 0x00000000 72 r
00001454 2020-06-29 17:36:43,1201372 +0,0000031 IRP_MJ_READ UP 0x00000000 73 s
00001456 2020-06-29 17:36:43,1201441 +0,0000030 IRP_MJ_READ UP 0x00000000 69 i
00001458 2020-06-29 17:36:43,1201511 +0,0000030 IRP_MJ_READ UP 0x00000000 6f o
00001460 2020-06-29 17:36:43,1201581 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00001462 2020-06-29 17:36:43,1201648 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00001464 2020-06-29 17:36:43,1201721 +0,0000031 IRP_MJ_READ UP 0x00000000 35 5
00001466 2020-06-29 17:36:43,1201788 +0,0000031 IRP_MJ_READ UP 0x00000000 2e .
00001468 2020-06-29 17:36:43,1201858 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00001470 2020-06-29 17:36:43,1201928 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00001472 2020-06-29 17:36:43,1201997 +0,0000030 IRP_MJ_READ UP 0x00000000 23 #
00001474 2020-06-29 17:36:43,1202064 +0,0000030 IRP_MJ_READ UP 0x00000000 31 1
00001476 2020-06-29 17:36:43,1202134 +0,0000030 IRP_MJ_READ UP 0x00000000 20
00001478 2020-06-29 17:36:43,1202204 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00001480 2020-06-29 17:36:43,1202274 +0,0000031 IRP_MJ_READ UP 0x00000000 2e .
00001482 2020-06-29 17:36:43,1202344 +0,0000031 IRP_MJ_READ UP 0x00000000 34 4
00001484 2020-06-29 17:36:43,1202414 +0,0000031 IRP_MJ_READ UP 0x00000000 38 8
00001486 2020-06-29 17:36:43,1202484 +0,0000031 IRP_MJ_READ UP 0x00000000 2e .
00001488 2020-06-29 17:36:43,1202553 +0,0000030 IRP_MJ_READ UP 0x00000000 32 2
00001490 2020-06-29 17:36:43,1202852 +0,0000260 IRP_MJ_READ UP 0x00000000 34 4
00001492 2020-06-29 17:36:43,1202944 +0,0000033 IRP_MJ_READ UP 0x00000000 0d .
00001494 2020-06-29 17:36:43,1203017 +0,0000033 IRP_MJ_READ UP 0x00000000 0a .
00001495 2020-06-29 17:36:43,1707564 +0,0504547 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 73 20 30 0d 0a ++eos 0..
00001497 2020-06-29 17:36:43,2723221 +0,1010410 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6d 6f 64 65 20 30 0d 0a ++mode 0..
00001500 2020-06-29 17:36:43,8241127 +0,5000256 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001501 2020-06-29 17:36:43,8241283 +0,0000156 IRP_MJ_READ UP 0xc0000120
00001502 2020-06-29 17:36:43,8241389 +0,0000106 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001503 2020-06-29 17:36:43,8748945 +0,0507556 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 69 20 31 0d 0a ++eoi 1..
00001506 2020-06-29 17:36:45,4491980 +1,4997987 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001507 2020-06-29 17:36:45,4492159 +0,0000179 IRP_MJ_READ UP 0xc0000120
00001508 2020-06-29 17:36:45,4492304 +0,0000145 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001510 2020-06-29 17:36:46,9716613 +1,4996070 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001511 2020-06-29 17:36:46,9716795 +0,0000182 IRP_MJ_READ UP 0xc0000120
00001512 2020-06-29 17:36:46,9716949 +0,0000154 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001514 2020-06-29 17:36:47,4775493 +0,4998092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001515 2020-06-29 17:36:47,4775652 +0,0000159 IRP_MJ_READ UP 0xc0000120
00001516 2020-06-29 17:36:47,4775792 +0,0000140 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001518 2020-06-29 17:36:47,9775637 +0,4999546 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001519 2020-06-29 17:36:47,9775799 +0,0000162 IRP_MJ_READ UP 0xc0000120
00001520 2020-06-29 17:36:47,9775938 +0,0000139 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001521 2020-06-29 17:36:47,9776081 +0,0000143 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR DOWN 0x00000000
00001522 2020-06-29 17:36:47,9782219 +0,0006138 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR UP 0x00000000
00001523 2020-06-29 17:36:47,9782358 +0,0000139 IRP_MJ_CLOSE DOWN 0x00000000
00001524 2020-06-29 17:36:48,0820387 +0,1038029 IRP_MJ_CLOSE UP 0x00000000
;----------------------------------------------------------------------
;If you have a Prologix GPIB-USB or other serial interface, you can
;modify the interface_settings line below to specify the interface's COM port and
;communications settings for use with the KE5FX GPIB Toolkit utilities.
;
;TCP/IP devices including the Prologix GPIB-LAN adapter can be supported by
;specifing their IP address or DNS name
;
;National Instruments GPIB interfaces other than GPIB0 may also be supported
;by editing interface_settings accordingly
;
;Examples:
;
; interface_settings GPIB1
; interface_settings com3:baud=115200 parity=N data=8 stop=1
; interface_settings ke5fx.dyndns.org
; interface_settings 192.168.1.103:1234
;
;To configure CONNECT.INI for use with your Prologix adapter, you can also use
;the PROLOGIX.EXE configurator included with the GPIB Toolkit distribution.
;
;NOTE: If you have an older Prologix board with DIP switches, you will need
;to set is_Prologix to 0 (below), since it cannot be automatically configured
;by the GPIB Toolkit applications. In case of difficulty, you can also
;download the legacy version of the GPIB Toolkit from the following link:
;[url]http://www.ke5fx.com/gpib/setup148.exe[/url]
;----------------------------------------------------------------------
interface_settings COM7:baud=115200 parity=N data=8 stop=1
;----------------------------------------------------------------------
;Fields below have no effect if National Instruments adapter is in use
;----------------------------------------------------------------------
;
;The is_Prologix flag should be set to 0 if you are using a non-Prologix
;serial or TCP/IP interface, such as a different adapter brand, or a direct RS-232
;cable connection to your instrument. Setting is_Prologix to 0 will prevent
;the Toolkit applications from transmitting Prologix-specific commands
;that will not be understood by the adapter or instrument in use
;
is_Prologix 1
;
;Some older Prologix boards may need a delay after writes to avoid
;buffer-overflow problems. Use 0 milliseconds for no delay
;
write_delay_ms 100
;
;Prologix controllers can reset the device to local operation when the
;GPIB connection is closed, but since most GPIB Toolkit applications use the
;Prologix adapter in auto-read mode (++auto 1), the final ++loc command has
;the effect of addressing the instrument to talk. This can cause error
;messages or connection problems with some equipment. You can avoid
;this behavior by setting reset_to_local to 0 to avoid transmitting
;an ++loc command altogether, or by setting restore_auto_read to 0 to
;force the Toolkit applications to leave auto-read disabled when they exit
;
;force_auto_read defaults to 1, as required by a number of older GPIB Toolkit
;applications. If you receive warning messages such as "Addressed to talk with
;nothing to say" when using the command line tools, you may be able to eliminate
;them by setting force_auto_read to 0. Otherwise this parameter should be left
;at its default value
;
;restore_auto_read defaults to 0. If set to 1, the Toolkit applications
;will restore the previous ++auto state at shutdown time. This may be
;necessary if you are running other applications that expect auto-read mode
;to be enabled
;
enable_LON 1
reset_to_local 0
force_auto_read 1
restore_auto_read 0
00000000 2020-06-30 11:23:58,6139211 PnP Event: Connect DOWN 0x00000000 5c 00 3f 00 3f 00 5c 00 46 00 54 00 44 00 49 00 42 00 55 00 … \.?.?.\.F.T.D.I.B.U.…
00000001 2020-06-30 11:24:04,9676053 +6,3536842 IRP_MJ_CREATE - process 63440 () DOWN 0x00000000
00000002 2020-06-30 11:24:04,9942149 +0,0266096 IRP_MJ_CREATE UP 0x00000000
00000003 2020-06-30 11:24:04,9942800 +0,0000651 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00000004 2020-06-30 11:24:04,9952214 +0,0009414 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00000023 2020-06-30 11:24:04,9954435 +0,0000061 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00000024 2020-06-30 11:24:04,9962129 +0,0007694 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00000025 2020-06-30 11:24:04,9962199 +0,0000070 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00000026 2020-06-30 11:24:04,9972091 +0,0009892 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00000027 2020-06-30 11:24:04,9972153 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00000028 2020-06-30 11:24:04,9982126 +0,0009973 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00000029 2020-06-30 11:24:04,9982173 +0,0000047 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00000030 2020-06-30 11:24:04,9982198 +0,0000025 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00000031 2020-06-30 11:24:04,9982240 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 09 00 00 00 80 00 00 00 00 04 00 00 00 04 00 00 ................
00000032 2020-06-30 11:24:05,0002204 +0,0019964 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00000033 2020-06-30 11:24:05,0002659 +0,0000455 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS DOWN 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00000034 2020-06-30 11:24:05,0002737 +0,0000078 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS UP 0x00000000
00000053 2020-06-30 11:24:05,0003531 +0,0000059 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00000054 2020-06-30 11:24:05,0012158 +0,0008627 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00000055 2020-06-30 11:24:05,0012250 +0,0000092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00000056 2020-06-30 11:24:05,0022237 +0,0009987 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00000057 2020-06-30 11:24:05,0022519 +0,0000282 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00000058 2020-06-30 11:24:05,0032104 +0,0009585 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00000059 2020-06-30 11:24:05,0032169 +0,0000065 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00000060 2020-06-30 11:24:05,0032208 +0,0000039 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00000061 2020-06-30 11:24:05,0032250 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 09 00 00 00 80 00 00 00 00 04 00 00 00 04 00 00 ................
00000062 2020-06-30 11:24:05,0042256 +0,0010006 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00000063 2020-06-30 11:24:05,0042516 +0,0000260 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000066 2020-06-30 11:24:05,3062506 +0,2011814 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000067 2020-06-30 11:24:05,3062674 +0,0000168 IRP_MJ_READ UP 0xc0000120
00000068 2020-06-30 11:24:05,3062772 +0,0000098 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000069 2020-06-30 11:24:05,3063012 +0,0000240 IRP_MJ_WRITE DOWN 0x00000000 76 65 72 0d 0a ver..
00000072 2020-06-30 11:24:05,4682304 +0,1609668 IRP_MJ_READ UP 0x00000000 41 A
00000074 2020-06-30 11:24:05,4682729 +0,0000154 IRP_MJ_READ UP 0x00000000 52 R
00000076 2020-06-30 11:24:05,4682818 +0,0000030 IRP_MJ_READ UP 0x00000000 34 4
00000078 2020-06-30 11:24:05,4682888 +0,0000031 IRP_MJ_READ UP 0x00000000 38 8
00000080 2020-06-30 11:24:05,4682958 +0,0000028 IRP_MJ_READ UP 0x00000000 38 8
00000082 2020-06-30 11:24:05,4683028 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00000084 2020-06-30 11:24:05,4683100 +0,0000030 IRP_MJ_READ UP 0x00000000 47 G
00000086 2020-06-30 11:24:05,4683170 +0,0000030 IRP_MJ_READ UP 0x00000000 50 P
00000088 2020-06-30 11:24:05,4683237 +0,0000028 IRP_MJ_READ UP 0x00000000 49 I
00000090 2020-06-30 11:24:05,4683307 +0,0000028 IRP_MJ_READ UP 0x00000000 42 B
00000092 2020-06-30 11:24:05,4683480 +0,0000030 IRP_MJ_READ UP 0x00000000 2d -
00000094 2020-06-30 11:24:05,4683559 +0,0000031 IRP_MJ_READ UP 0x00000000 55 U
00000096 2020-06-30 11:24:05,4683637 +0,0000031 IRP_MJ_READ UP 0x00000000 53 S
00000098 2020-06-30 11:24:05,4683718 +0,0000042 IRP_MJ_READ UP 0x00000000 42 B
00000100 2020-06-30 11:24:05,4683788 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00000102 2020-06-30 11:24:05,4683858 +0,0000031 IRP_MJ_READ UP 0x00000000 2c ,
00000104 2020-06-30 11:24:05,4683927 +0,0000030 IRP_MJ_READ UP 0x00000000 20
00000106 2020-06-30 11:24:05,4683997 +0,0000031 IRP_MJ_READ UP 0x00000000 76 v
00000108 2020-06-30 11:24:05,4684064 +0,0000030 IRP_MJ_READ UP 0x00000000 65 e
00000110 2020-06-30 11:24:05,4684134 +0,0000031 IRP_MJ_READ UP 0x00000000 72 r
00000112 2020-06-30 11:24:05,4684204 +0,0000031 IRP_MJ_READ UP 0x00000000 73 s
00000114 2020-06-30 11:24:05,4684271 +0,0000028 IRP_MJ_READ UP 0x00000000 69 i
00000116 2020-06-30 11:24:05,4684341 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00000118 2020-06-30 11:24:05,4684411 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00000120 2020-06-30 11:24:05,4684478 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00000122 2020-06-30 11:24:05,4684548 +0,0000031 IRP_MJ_READ UP 0x00000000 35 5
00000124 2020-06-30 11:24:05,4684617 +0,0000030 IRP_MJ_READ UP 0x00000000 2e .
00000126 2020-06-30 11:24:05,4684684 +0,0000030 IRP_MJ_READ UP 0x00000000 30 0
00000128 2020-06-30 11:24:05,4684751 +0,0000027 IRP_MJ_READ UP 0x00000000 20
00000130 2020-06-30 11:24:05,4684824 +0,0000031 IRP_MJ_READ UP 0x00000000 23 #
00000132 2020-06-30 11:24:05,4684891 +0,0000031 IRP_MJ_READ UP 0x00000000 31 1
00000134 2020-06-30 11:24:05,4684961 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00000136 2020-06-30 11:24:05,4685034 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00000138 2020-06-30 11:24:05,4685101 +0,0000031 IRP_MJ_READ UP 0x00000000 2e .
00000140 2020-06-30 11:24:05,4685171 +0,0000031 IRP_MJ_READ UP 0x00000000 34 4
00000142 2020-06-30 11:24:05,4685252 +0,0000042 IRP_MJ_READ UP 0x00000000 38 8
00000144 2020-06-30 11:24:05,4685319 +0,0000028 IRP_MJ_READ UP 0x00000000 2e .
00000146 2020-06-30 11:24:05,4685388 +0,0000030 IRP_MJ_READ UP 0x00000000 32 2
00000148 2020-06-30 11:24:05,4685458 +0,0000030 IRP_MJ_READ UP 0x00000000 34 4
00000150 2020-06-30 11:24:05,4685528 +0,0000031 IRP_MJ_READ UP 0x00000000 0d .
00000152 2020-06-30 11:24:05,4685598 +0,0000031 IRP_MJ_READ UP 0x00000000 0a .
00000153 2020-06-30 11:24:05,4690140 +0,0004542 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000156 2020-06-30 11:24:05,5943529 +0,1006109 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000157 2020-06-30 11:24:05,5943677 +0,0000148 IRP_MJ_READ UP 0xc0000120
00000158 2020-06-30 11:24:05,5943761 +0,0000084 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000159 2020-06-30 11:24:05,5944015 +0,0000254 IRP_MJ_WRITE DOWN 0x00000000 6d 6f 64 65 0d 0a mode..
00000162 2020-06-30 11:24:06,1021956 +0,5069560 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000163 2020-06-30 11:24:06,1022132 +0,0000176 IRP_MJ_READ UP 0xc0000120
00000164 2020-06-30 11:24:06,1022216 +0,0000084 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000165 2020-06-30 11:24:06,1024828 +0,0002612 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000168 2020-06-30 11:24:06,2291545 +0,1005913 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000169 2020-06-30 11:24:06,2291704 +0,0000159 IRP_MJ_READ UP 0xc0000120
00000170 2020-06-30 11:24:06,2291794 +0,0000090 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000171 2020-06-30 11:24:06,2292062 +0,0000268 IRP_MJ_WRITE DOWN 0x00000000 61 64 64 72 0d 0a addr..
00000174 2020-06-30 11:24:06,6682581 +0,4379981 IRP_MJ_READ UP 0x00000000 55 U
00000176 2020-06-30 11:24:06,6683005 +0,0000159 IRP_MJ_READ UP 0x00000000 6e n
00000178 2020-06-30 11:24:06,6683092 +0,0000031 IRP_MJ_READ UP 0x00000000 72 r
00000180 2020-06-30 11:24:06,6683162 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00000182 2020-06-30 11:24:06,6683235 +0,0000034 IRP_MJ_READ UP 0x00000000 63 c
00000184 2020-06-30 11:24:06,6683304 +0,0000033 IRP_MJ_READ UP 0x00000000 6f o
00000186 2020-06-30 11:24:06,6683383 +0,0000040 IRP_MJ_READ UP 0x00000000 67 g
00000188 2020-06-30 11:24:06,6683452 +0,0000030 IRP_MJ_READ UP 0x00000000 6e n
00000190 2020-06-30 11:24:06,6683519 +0,0000027 IRP_MJ_READ UP 0x00000000 69 i
00000192 2020-06-30 11:24:06,6683589 +0,0000030 IRP_MJ_READ UP 0x00000000 7a z
00000194 2020-06-30 11:24:06,6683659 +0,0000031 IRP_MJ_READ UP 0x00000000 65 e
00000196 2020-06-30 11:24:06,6683729 +0,0000031 IRP_MJ_READ UP 0x00000000 64 d
00000198 2020-06-30 11:24:06,6683796 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00000200 2020-06-30 11:24:06,6683866 +0,0000028 IRP_MJ_READ UP 0x00000000 63 c
00000202 2020-06-30 11:24:06,6683936 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00000204 2020-06-30 11:24:06,6684006 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000206 2020-06-30 11:24:06,6684073 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000208 2020-06-30 11:24:06,6684142 +0,0000030 IRP_MJ_READ UP 0x00000000 61 a
00000210 2020-06-30 11:24:06,6684212 +0,0000030 IRP_MJ_READ UP 0x00000000 6e n
00000212 2020-06-30 11:24:06,6684279 +0,0000028 IRP_MJ_READ UP 0x00000000 64 d
00000214 2020-06-30 11:24:06,6684349 +0,0000031 IRP_MJ_READ UP 0x00000000 0d .
00000216 2020-06-30 11:24:06,6684419 +0,0000031 IRP_MJ_READ UP 0x00000000 0a .
00000217 2020-06-30 11:24:06,6686305 +0,0001886 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000220 2020-06-30 11:24:06,8951987 +0,2011667 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000221 2020-06-30 11:24:06,8952143 +0,0000156 IRP_MJ_READ UP 0xc0000120
00000222 2020-06-30 11:24:06,8952232 +0,0000089 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000223 2020-06-30 11:24:06,8952464 +0,0000232 IRP_MJ_WRITE DOWN 0x00000000 65 6f 69 0d 0a eoi..
00000226 2020-06-30 11:24:07,4040181 +0,5077791 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000227 2020-06-30 11:24:07,4040326 +0,0000145 IRP_MJ_READ UP 0xc0000120
00000228 2020-06-30 11:24:07,4040415 +0,0000089 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000229 2020-06-30 11:24:07,4040773 +0,0000358 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000232 2020-06-30 11:24:07,5299994 +0,1005778 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000233 2020-06-30 11:24:07,5300143 +0,0000149 IRP_MJ_READ UP 0xc0000120
00000234 2020-06-30 11:24:07,5300226 +0,0000083 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000235 2020-06-30 11:24:07,5300481 +0,0000255 IRP_MJ_WRITE DOWN 0x00000000 65 6f 74 5f 65 6e 61 62 6c 65 0d 0a eot_enable..
00000238 2020-06-30 11:24:07,8682483 +0,3369948 IRP_MJ_READ UP 0x00000000 55 U
00000240 2020-06-30 11:24:07,8683000 +0,0000162 IRP_MJ_READ UP 0x00000000 6e n
00000242 2020-06-30 11:24:07,8683089 +0,0000030 IRP_MJ_READ UP 0x00000000 72 r
00000244 2020-06-30 11:24:07,8683159 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00000246 2020-06-30 11:24:07,8683240 +0,0000039 IRP_MJ_READ UP 0x00000000 63 c
00000248 2020-06-30 11:24:07,8683310 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00000250 2020-06-30 11:24:07,8683383 +0,0000031 IRP_MJ_READ UP 0x00000000 67 g
00000252 2020-06-30 11:24:07,8683450 +0,0000028 IRP_MJ_READ UP 0x00000000 6e n
00000254 2020-06-30 11:24:07,8683519 +0,0000030 IRP_MJ_READ UP 0x00000000 69 i
00000256 2020-06-30 11:24:07,8683587 +0,0000028 IRP_MJ_READ UP 0x00000000 7a z
00000258 2020-06-30 11:24:07,8683656 +0,0000030 IRP_MJ_READ UP 0x00000000 65 e
00000260 2020-06-30 11:24:07,8683726 +0,0000031 IRP_MJ_READ UP 0x00000000 64 d
00000262 2020-06-30 11:24:07,8683796 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00000264 2020-06-30 11:24:07,8683863 +0,0000028 IRP_MJ_READ UP 0x00000000 63 c
00000266 2020-06-30 11:24:07,8683933 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00000268 2020-06-30 11:24:07,8684003 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000270 2020-06-30 11:24:07,8684073 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000272 2020-06-30 11:24:07,8684140 +0,0000028 IRP_MJ_READ UP 0x00000000 61 a
00000274 2020-06-30 11:24:07,8684210 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00000276 2020-06-30 11:24:07,8684279 +0,0000030 IRP_MJ_READ UP 0x00000000 64 d
00000278 2020-06-30 11:24:07,8684346 +0,0000028 IRP_MJ_READ UP 0x00000000 0d .
00000280 2020-06-30 11:24:07,8684422 +0,0000034 IRP_MJ_READ UP 0x00000000 0a .
00000281 2020-06-30 11:24:07,8684852 +0,0000430 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000284 2020-06-30 11:24:08,0954587 +0,2012021 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000285 2020-06-30 11:24:08,0954738 +0,0000151 IRP_MJ_READ UP 0xc0000120
00000286 2020-06-30 11:24:08,0954814 +0,0000076 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000287 2020-06-30 11:24:08,0955076 +0,0000262 IRP_MJ_WRITE DOWN 0x00000000 65 6f 74 5f 63 68 61 72 0d 0a eot_char..
00000290 2020-06-30 11:24:08,6033049 +0,5070726 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000291 2020-06-30 11:24:08,6033188 +0,0000139 IRP_MJ_READ UP 0xc0000120
00000292 2020-06-30 11:24:08,6033300 +0,0000112 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000293 2020-06-30 11:24:08,6034758 +0,0001458 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000296 2020-06-30 11:24:08,7302584 +0,1005935 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000297 2020-06-30 11:24:08,7302732 +0,0000148 IRP_MJ_READ UP 0xc0000120
00000298 2020-06-30 11:24:08,7302819 +0,0000087 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000299 2020-06-30 11:24:08,7303062 +0,0000243 IRP_MJ_WRITE DOWN 0x00000000 65 6f 73 0d 0a eos..
00000302 2020-06-30 11:24:09,0682564 +0,3370051 IRP_MJ_READ UP 0x00000000 55 U
00000304 2020-06-30 11:24:09,0683036 +0,0000165 IRP_MJ_READ UP 0x00000000 6e n
00000306 2020-06-30 11:24:09,0683123 +0,0000031 IRP_MJ_READ UP 0x00000000 72 r
00000308 2020-06-30 11:24:09,0683193 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00000310 2020-06-30 11:24:09,0683262 +0,0000030 IRP_MJ_READ UP 0x00000000 63 c
00000312 2020-06-30 11:24:09,0683332 +0,0000030 IRP_MJ_READ UP 0x00000000 6f o
00000314 2020-06-30 11:24:09,0683399 +0,0000028 IRP_MJ_READ UP 0x00000000 67 g
00000316 2020-06-30 11:24:09,0683469 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00000318 2020-06-30 11:24:09,0683536 +0,0000030 IRP_MJ_READ UP 0x00000000 69 i
00000320 2020-06-30 11:24:09,0683603 +0,0000028 IRP_MJ_READ UP 0x00000000 7a z
00000322 2020-06-30 11:24:09,0683670 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00000324 2020-06-30 11:24:09,0683740 +0,0000031 IRP_MJ_READ UP 0x00000000 64 d
00000326 2020-06-30 11:24:09,0683810 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00000328 2020-06-30 11:24:09,0683877 +0,0000028 IRP_MJ_READ UP 0x00000000 63 c
00000330 2020-06-30 11:24:09,0683950 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00000332 2020-06-30 11:24:09,0684017 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000334 2020-06-30 11:24:09,0684084 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000336 2020-06-30 11:24:09,0684154 +0,0000031 IRP_MJ_READ UP 0x00000000 61 a
00000338 2020-06-30 11:24:09,0684221 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00000340 2020-06-30 11:24:09,0684288 +0,0000031 IRP_MJ_READ UP 0x00000000 64 d
00000342 2020-06-30 11:24:09,0684355 +0,0000028 IRP_MJ_READ UP 0x00000000 0d .
00000344 2020-06-30 11:24:09,0684425 +0,0000031 IRP_MJ_READ UP 0x00000000 0a .
00000346 2020-06-30 11:24:09,1218777 +0,0501471 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000347 2020-06-30 11:24:09,1218926 +0,0000149 IRP_MJ_READ UP 0xc0000120
00000696 2020-06-30 11:24:18,6048263 +0,0000084 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000698 2020-06-30 11:24:18,7093139 +0,0507744 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000699 2020-06-30 11:24:18,7093292 +0,0000153 IRP_MJ_READ UP 0xc0000120
00000700 2020-06-30 11:24:18,7093401 +0,0000109 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000702 2020-06-30 11:24:18,8646174 +0,1003457 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000703 2020-06-30 11:24:18,8646333 +0,0000159 IRP_MJ_READ UP 0xc0000120
00000704 2020-06-30 11:24:18,8646428 +0,0000095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000705 2020-06-30 11:24:18,8646800 +0,0000372 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6c 6f 6e 20 31 0d 0a ++lon 1..
00000708 2020-06-30 11:24:19,0159612 +0,0507866 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000709 2020-06-30 11:24:19,0159771 +0,0000159 IRP_MJ_READ UP 0xc0000120
00000710 2020-06-30 11:24:19,0159866 +0,0000095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000711 2020-06-30 11:24:19,0160104 +0,0000238 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000714 2020-06-30 11:24:19,1419409 +0,1006111 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000715 2020-06-30 11:24:19,1419560 +0,0000151 IRP_MJ_READ UP 0xc0000120
00000716 2020-06-30 11:24:19,1419652 +0,0000092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000717 2020-06-30 11:24:19,1419895 +0,0000243 IRP_MJ_WRITE DOWN 0x00000000 6d 6f 64 65 0d 0a mode..
00000720 2020-06-30 11:24:19,6498122 +0,5075729 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000721 2020-06-30 11:24:19,6498278 +0,0000156 IRP_MJ_READ UP 0xc0000120
00000722 2020-06-30 11:24:19,6498373 +0,0000095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000723 2020-06-30 11:24:19,6498711 +0,0000338 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000726 2020-06-30 11:24:19,7757642 +0,1005949 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000727 2020-06-30 11:24:19,7757793 +0,0000151 IRP_MJ_READ UP 0xc0000120
00000728 2020-06-30 11:24:19,7757879 +0,0000086 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000729 2020-06-30 11:24:19,7758145 +0,0000266 IRP_MJ_WRITE DOWN 0x00000000 61 64 64 72 0d 0a addr..
00000732 2020-06-30 11:24:20,2836003 +0,5073643 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000733 2020-06-30 11:24:20,2836159 +0,0000156 IRP_MJ_READ UP 0xc0000120
00000734 2020-06-30 11:24:20,2836234 +0,0000075 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000735 2020-06-30 11:24:20,2837570 +0,0001336 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000738 2020-06-30 11:24:20,5101810 +0,2011753 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000739 2020-06-30 11:24:20,5102006 +0,0000196 IRP_MJ_READ UP 0xc0000120
00000740 2020-06-30 11:24:20,5102123 +0,0000117 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000741 2020-06-30 11:24:20,5102411 +0,0000288 IRP_MJ_WRITE DOWN 0x00000000 65 6f 69 0d 0a eoi..
00000744 2020-06-30 11:24:21,0190041 +0,5077534 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000745 2020-06-30 11:24:21,0190203 +0,0000162 IRP_MJ_READ UP 0xc0000120
00000746 2020-06-30 11:24:21,0190300 +0,0000097 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000747 2020-06-30 11:24:21,0190675 +0,0000375 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000750 2020-06-30 11:24:21,1459498 +0,1005720 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000751 2020-06-30 11:24:21,1459649 +0,0000151 IRP_MJ_READ UP 0xc0000120
00000752 2020-06-30 11:24:21,1459727 +0,0000078 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000753 2020-06-30 11:24:21,1459973 +0,0000246 IRP_MJ_WRITE DOWN 0x00000000 65 6f 74 5f 65 6e 61 62 6c 65 0d 0a eot_enable..
00000756 2020-06-30 11:24:21,6538197 +0,5075763 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000757 2020-06-30 11:24:21,6538356 +0,0000159 IRP_MJ_READ UP 0xc0000120
00000758 2020-06-30 11:24:21,6538448 +0,0000092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000759 2020-06-30 11:24:21,6538842 +0,0000394 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000762 2020-06-30 11:24:21,7797734 +0,1006069 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000763 2020-06-30 11:24:21,7797887 +0,0000153 IRP_MJ_READ UP 0xc0000120
00000764 2020-06-30 11:24:21,7797974 +0,0000087 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000765 2020-06-30 11:24:21,7798228 +0,0000254 IRP_MJ_WRITE DOWN 0x00000000 65 6f 74 5f 63 68 61 72 0d 0a eot_char..
00000768 2020-06-30 11:24:22,2652588 +0,4850186 IRP_MJ_READ UP 0x00000000 55 U
00000770 2020-06-30 11:24:22,2653105 +0,0000162 IRP_MJ_READ UP 0x00000000 6e n
00000772 2020-06-30 11:24:22,2653194 +0,0000030 IRP_MJ_READ UP 0x00000000 72 r
00000774 2020-06-30 11:24:22,2653264 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00000776 2020-06-30 11:24:22,2653348 +0,0000045 IRP_MJ_READ UP 0x00000000 63 c
00000778 2020-06-30 11:24:22,2653418 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00000780 2020-06-30 11:24:22,2653485 +0,0000031 IRP_MJ_READ UP 0x00000000 67 g
00000782 2020-06-30 11:24:22,2653555 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00000784 2020-06-30 11:24:22,2653622 +0,0000031 IRP_MJ_READ UP 0x00000000 69 i
00000786 2020-06-30 11:24:22,2653689 +0,0000028 IRP_MJ_READ UP 0x00000000 7a z
00000788 2020-06-30 11:24:22,2653759 +0,0000031 IRP_MJ_READ UP 0x00000000 65 e
00000790 2020-06-30 11:24:22,2653831 +0,0000030 IRP_MJ_READ UP 0x00000000 64 d
00000792 2020-06-30 11:24:22,2653901 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00000794 2020-06-30 11:24:22,2653968 +0,0000028 IRP_MJ_READ UP 0x00000000 63 c
00000796 2020-06-30 11:24:22,2654038 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00000798 2020-06-30 11:24:22,2654105 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000800 2020-06-30 11:24:22,2654172 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00000802 2020-06-30 11:24:22,2654239 +0,0000028 IRP_MJ_READ UP 0x00000000 61 a
00000804 2020-06-30 11:24:22,2654309 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00000806 2020-06-30 11:24:22,2654379 +0,0000031 IRP_MJ_READ UP 0x00000000 64 d
00000808 2020-06-30 11:24:22,2654446 +0,0000031 IRP_MJ_READ UP 0x00000000 0d .
00000810 2020-06-30 11:24:22,2654516 +0,0000031 IRP_MJ_READ UP 0x00000000 0a .
00000811 2020-06-30 11:24:22,2655854 +0,0001338 IRP_MJ_WRITE DOWN 0x00000000 2b 2b ++
00000814 2020-06-30 11:24:22,3921397 +0,1006242 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000815 2020-06-30 11:24:22,3921554 +0,0000157 IRP_MJ_READ UP 0xc0000120
00000816 2020-06-30 11:24:22,3921627 +0,0000073 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000817 2020-06-30 11:24:22,3921872 +0,0000245 IRP_MJ_WRITE DOWN 0x00000000 65 6f 73 0d 0a eos..
00000820 2020-06-30 11:24:22,9009371 +0,5076830 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000821 2020-06-30 11:24:22,9009550 +0,0000179 IRP_MJ_READ UP 0xc0000120
00000822 2020-06-30 11:24:22,9009656 +0,0000106 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000824 2020-06-30 11:24:32,0078468 +0,0000195 IRP_MJ_READ UP 0x00000000 30 0
00000826 2020-06-30 11:24:32,0078603 +0,0000040 IRP_MJ_READ UP 0x00000000 0d .
00000828 2020-06-30 11:24:32,0078689 +0,0000033 IRP_MJ_READ UP 0x00000000 0a .
00000830 2020-06-30 11:24:32,2626538 +0,2537903 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000831 2020-06-30 11:24:32,2626689 +0,0000151 IRP_MJ_READ UP 0xc0000120
00000832 2020-06-30 11:24:32,2626764 +0,0000075 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000834 2020-06-30 11:24:32,3134150 +0,0503150 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000835 2020-06-30 11:24:32,3134318 +0,0000168 IRP_MJ_READ UP 0xc0000120
00000960 2020-06-30 11:24:35,6622364 +0,0000089 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000962 2020-06-30 11:24:35,7667478 +0,0507908 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000963 2020-06-30 11:24:35,7667629 +0,0000151 IRP_MJ_READ UP 0xc0000120
00000964 2020-06-30 11:24:35,7667735 +0,0000106 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000966 2020-06-30 11:24:35,8819515 +0,0507291 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000967 2020-06-30 11:24:35,8819669 +0,0000154 IRP_MJ_READ UP 0xc0000120
00000968 2020-06-30 11:24:35,8819755 +0,0000086 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000970 2020-06-30 11:24:35,9874258 +0,0504734 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00000971 2020-06-30 11:24:35,9874406 +0,0000148 IRP_MJ_READ UP 0xc0000120
00000972 2020-06-30 11:24:35,9874482 +0,0000076 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00000973 2020-06-30 11:24:36,0196539 +0,0322057 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR DOWN 0x00000000
00000974 2020-06-30 11:24:36,0202015 +0,0005476 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR UP 0x00000000
00000975 2020-06-30 11:24:36,0202339 +0,0000324 IRP_MJ_CLOSE DOWN 0x00000000
00000976 2020-06-30 11:24:36,1378109 +0,1175770 IRP_MJ_CLOSE UP 0x00000000
00000977 2020-06-30 11:24:47,0349609 +10,8971500 IRP_MJ_CREATE - process 36256 () DOWN 0x00000000
00000978 2020-06-30 11:24:47,0551640 +0,0202031 IRP_MJ_CREATE UP 0x00000000
00000979 2020-06-30 11:24:47,0552193 +0,0000553 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00000980 2020-06-30 11:24:47,0561591 +0,0009398 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00000999 2020-06-30 11:24:47,0563877 +0,0000059 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00001000 2020-06-30 11:24:47,0571590 +0,0007713 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00001001 2020-06-30 11:24:47,0571665 +0,0000075 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00001002 2020-06-30 11:24:47,0581616 +0,0009951 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00001003 2020-06-30 11:24:47,0581678 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00001004 2020-06-30 11:24:47,0591576 +0,0009898 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00001005 2020-06-30 11:24:47,0591623 +0,0000047 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00001006 2020-06-30 11:24:47,0591654 +0,0000031 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00001007 2020-06-30 11:24:47,0591696 +0,0000042 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 09 00 00 00 80 00 00 00 00 04 00 00 00 04 00 00 ................
00001008 2020-06-30 11:24:47,0601582 +0,0009886 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00001009 2020-06-30 11:24:47,0601661 +0,0000079 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS DOWN 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00001010 2020-06-30 11:24:47,0601689 +0,0000028 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS UP 0x00000000
00001029 2020-06-30 11:24:47,0602365 +0,0000056 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00001030 2020-06-30 11:24:47,0611662 +0,0009297 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00001031 2020-06-30 11:24:47,0611729 +0,0000067 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS DOWN 0x00000000
00001032 2020-06-30 11:24:47,0611757 +0,0000028 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS UP 0xc000000d
00001033 2020-06-30 11:24:47,0611824 +0,0000067 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00001034 2020-06-30 11:24:47,0621585 +0,0009761 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00001035 2020-06-30 11:24:47,0621641 +0,0000056 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00001036 2020-06-30 11:24:47,0631583 +0,0009942 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00001037 2020-06-30 11:24:47,0631634 +0,0000051 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00001038 2020-06-30 11:24:47,0631656 +0,0000022 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00001039 2020-06-30 11:24:47,0631695 +0,0000039 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 01 00 00 00 40 00 00 00 00 04 00 00 00 04 00 00 ....@...........
00001040 2020-06-30 11:24:47,0651823 +0,0020128 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00001041 2020-06-30 11:24:47,0905596 +0,0253773 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 76 65 72 0d 0a ++ver..
00001044 2020-06-30 11:24:47,4491767 +0,3579639 IRP_MJ_READ UP 0x00000000 41 A
00001046 2020-06-30 11:24:47,4492460 +0,0000148 IRP_MJ_READ UP 0x00000000 52 R
00001048 2020-06-30 11:24:47,4492546 +0,0000030 IRP_MJ_READ UP 0x00000000 34 4
00001050 2020-06-30 11:24:47,4652092 +0,0159504 IRP_MJ_READ UP 0x00000000 38 8
00001052 2020-06-30 11:24:47,4652421 +0,0000100 IRP_MJ_READ UP 0x00000000 38 8
00001054 2020-06-30 11:24:47,4652508 +0,0000034 IRP_MJ_READ UP 0x00000000 20
00001056 2020-06-30 11:24:47,4652581 +0,0000031 IRP_MJ_READ UP 0x00000000 47 G
00001058 2020-06-30 11:24:47,4652650 +0,0000030 IRP_MJ_READ UP 0x00000000 50 P
00001060 2020-06-30 11:24:47,4652720 +0,0000030 IRP_MJ_READ UP 0x00000000 49 I
00001062 2020-06-30 11:24:47,4652787 +0,0000028 IRP_MJ_READ UP 0x00000000 42 B
00001064 2020-06-30 11:24:47,4652854 +0,0000028 IRP_MJ_READ UP 0x00000000 2d -
00001066 2020-06-30 11:24:47,4652930 +0,0000031 IRP_MJ_READ UP 0x00000000 55 U
00001068 2020-06-30 11:24:47,4653000 +0,0000031 IRP_MJ_READ UP 0x00000000 53 S
00001070 2020-06-30 11:24:47,4653067 +0,0000031 IRP_MJ_READ UP 0x00000000 42 B
00001072 2020-06-30 11:24:47,4653136 +0,0000030 IRP_MJ_READ UP 0x00000000 20
00001074 2020-06-30 11:24:47,4653206 +0,0000030 IRP_MJ_READ UP 0x00000000 2c ,
00001076 2020-06-30 11:24:47,4653273 +0,0000030 IRP_MJ_READ UP 0x00000000 20
00001078 2020-06-30 11:24:47,4653340 +0,0000028 IRP_MJ_READ UP 0x00000000 76 v
00001080 2020-06-30 11:24:47,4653410 +0,0000028 IRP_MJ_READ UP 0x00000000 65 e
00001082 2020-06-30 11:24:47,4653477 +0,0000028 IRP_MJ_READ UP 0x00000000 72 r
00001084 2020-06-30 11:24:47,4653547 +0,0000031 IRP_MJ_READ UP 0x00000000 73 s
00001086 2020-06-30 11:24:47,4653614 +0,0000028 IRP_MJ_READ UP 0x00000000 69 i
00001088 2020-06-30 11:24:47,4653684 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00001090 2020-06-30 11:24:47,4653751 +0,0000028 IRP_MJ_READ UP 0x00000000 6e n
00001092 2020-06-30 11:24:47,4653821 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00001094 2020-06-30 11:24:47,4653888 +0,0000028 IRP_MJ_READ UP 0x00000000 35 5
00001096 2020-06-30 11:24:47,4653955 +0,0000028 IRP_MJ_READ UP 0x00000000 2e .
00001098 2020-06-30 11:24:47,4654022 +0,0000028 IRP_MJ_READ UP 0x00000000 30 0
00001100 2020-06-30 11:24:47,4654092 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00001102 2020-06-30 11:24:47,4654159 +0,0000028 IRP_MJ_READ UP 0x00000000 23 #
00001104 2020-06-30 11:24:47,4654226 +0,0000028 IRP_MJ_READ UP 0x00000000 31 1
00001106 2020-06-30 11:24:47,4654296 +0,0000028 IRP_MJ_READ UP 0x00000000 20
00001108 2020-06-30 11:24:47,4654363 +0,0000028 IRP_MJ_READ UP 0x00000000 30 0
00001110 2020-06-30 11:24:47,4654433 +0,0000031 IRP_MJ_READ UP 0x00000000 2e .
00001112 2020-06-30 11:24:47,4654500 +0,0000028 IRP_MJ_READ UP 0x00000000 34 4
00001114 2020-06-30 11:24:47,4654567 +0,0000028 IRP_MJ_READ UP 0x00000000 38 8
00001116 2020-06-30 11:24:47,4654637 +0,0000031 IRP_MJ_READ UP 0x00000000 2e .
00001118 2020-06-30 11:24:47,4654704 +0,0000031 IRP_MJ_READ UP 0x00000000 32 2
00001120 2020-06-30 11:24:47,4654771 +0,0000028 IRP_MJ_READ UP 0x00000000 34 4
00001122 2020-06-30 11:24:47,4654841 +0,0000031 IRP_MJ_READ UP 0x00000000 0d .
00001124 2020-06-30 11:24:47,4654908 +0,0000031 IRP_MJ_READ UP 0x00000000 0a .
00001125 2020-06-30 11:24:47,4655229 +0,0000321 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 73 20 30 0d 0a ++eos 0..
00001127 2020-06-30 11:24:47,4661847 +0,0000176 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6d 6f 64 65 20 30 0d 0a ++mode 0..
00001130 2020-06-30 11:24:47,9666078 +0,4994339 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001131 2020-06-30 11:24:47,9666240 +0,0000162 IRP_MJ_READ UP 0xc0000120
00001132 2020-06-30 11:24:47,9666327 +0,0000087 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001133 2020-06-30 11:24:47,9666533 +0,0000206 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 69 20 31 0d 0a ++eoi 1..
00001136 2020-06-30 11:24:49,4998585 +1,4992626 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001137 2020-06-30 11:24:49,4998736 +0,0000151 IRP_MJ_READ UP 0xc0000120
00001138 2020-06-30 11:24:49,4998820 +0,0000084 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001140 2020-06-30 11:24:51,0331420 +1,4992582 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001141 2020-06-30 11:24:51,0331573 +0,0000153 IRP_MJ_READ UP 0xc0000120
00001142 2020-06-30 11:24:51,0331665 +0,0000092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001144 2020-06-30 11:24:52,5654465 +1,4993171 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001145 2020-06-30 11:24:52,5654624 +0,0000159 IRP_MJ_READ UP 0xc0000120
00001146 2020-06-30 11:24:52,5654719 +0,0000095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001148 2020-06-30 11:24:54,0987330 +1,4994344 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001149 2020-06-30 11:24:54,0987495 +0,0000165 IRP_MJ_READ UP 0xc0000120
00001150 2020-06-30 11:24:54,0987601 +0,0000106 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001152 2020-06-30 11:24:55,6310755 +1,4994048 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001153 2020-06-30 11:24:55,6310923 +0,0000168 IRP_MJ_READ UP 0xc0000120
00001154 2020-06-30 11:24:55,6311009 +0,0000086 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001156 2020-06-30 11:24:57,1633454 +1,4991978 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001157 2020-06-30 11:24:57,1633616 +0,0000162 IRP_MJ_READ UP 0xc0000120
00001158 2020-06-30 11:24:57,1633711 +0,0000095 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001160 2020-06-30 11:24:58,6921962 +1,4994642 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001161 2020-06-30 11:24:58,6922121 +0,0000159 IRP_MJ_READ UP 0xc0000120
00001162 2020-06-30 11:24:58,6922211 +0,0000090 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001164 2020-06-30 11:25:00,2244633 +1,4992671 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001165 2020-06-30 11:25:00,2244798 +0,0000165 IRP_MJ_READ UP 0xc0000120
00001166 2020-06-30 11:25:00,2244895 +0,0000097 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001168 2020-06-30 11:25:01,7577456 +1,4998026 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00001169 2020-06-30 11:25:01,7577615 +0,0000159 IRP_MJ_READ UP 0xc0000120
00001170 2020-06-30 11:25:01,7577707 +0,0000092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00001172 2020-06-30 11:25:03,2597119 +1,4689532 IRP_MJ_READ UP 0x00000000 49 I
00001174 2020-06-30 11:25:03,2928390 +0,0000268 IRP_MJ_READ UP 0x00000000 4e N
00001176 2020-06-30 11:25:03,2928538 +0,0000064 IRP_MJ_READ UP 0x00000000 3b ;
00001178 2020-06-30 11:25:03,2928616 +0,0000036 IRP_MJ_READ UP 0x00000000 53 S
00001180 2020-06-30 11:25:03,2928686 +0,0000030 IRP_MJ_READ UP 0x00000000 50 P
00001182 2020-06-30 11:25:03,2928753 +0,0000030 IRP_MJ_READ UP 0x00000000 3b ;
00001184 2020-06-30 11:25:03,2928823 +0,0000028 IRP_MJ_READ UP 0x00000000 53 S
00001186 2020-06-30 11:25:03,2928893 +0,0000028 IRP_MJ_READ UP 0x00000000 43 C
00001188 2020-06-30 11:25:03,2928980 +0,0000028 IRP_MJ_READ UP 0x00000000 30 0
00001190 2020-06-30 11:25:03,2929047 +0,0000028 IRP_MJ_READ UP 0x00000000 2c ,
00001192 2020-06-30 11:25:03,2929116 +0,0000027 IRP_MJ_READ UP 0x00000000 36 6
00001194 2020-06-30 11:25:03,2929189 +0,0000031 IRP_MJ_READ UP 0x00000000 34 4
00001196 2020-06-30 11:25:03,2929259 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00001198 2020-06-30 11:25:03,2929326 +0,0000028 IRP_MJ_READ UP 0x00000000 2c ,
00001200 2020-06-30 11:25:03,2929396 +0,0000028 IRP_MJ_READ UP 0x00000000 30 0
00001202 2020-06-30 11:25:03,2929466 +0,0000028 IRP_MJ_READ UP 0x00000000 2c ,
00001204 2020-06-30 11:25:03,2929600 +0,0000031 IRP_MJ_READ UP 0x00000000 34 4
00001206 2020-06-30 11:25:03,2929670 +0,0000028 IRP_MJ_READ UP 0x00000000 38 8
00051410 2020-06-30 11:25:08,1596891 +0,0000030 IRP_MJ_READ UP 0x00000000 50 P
00051412 2020-06-30 11:25:08,1596961 +0,0000031 IRP_MJ_READ UP 0x00000000 41 A
00051414 2020-06-30 11:25:08,1597031 +0,0000031 IRP_MJ_READ UP 0x00000000 33 3
00051416 2020-06-30 11:25:08,1597101 +0,0000031 IRP_MJ_READ UP 0x00000000 39 9
00051418 2020-06-30 11:25:08,1597171 +0,0000031 IRP_MJ_READ UP 0x00000000 37 7
00051420 2020-06-30 11:25:08,1597240 +0,0000030 IRP_MJ_READ UP 0x00000000 2c ,
00051422 2020-06-30 11:25:08,1597310 +0,0000030 IRP_MJ_READ UP 0x00000000 34 4
00051424 2020-06-30 11:25:08,1597380 +0,0000031 IRP_MJ_READ UP 0x00000000 35 5
00051426 2020-06-30 11:25:08,1597450 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00051428 2020-06-30 11:25:08,1597520 +0,0000028 IRP_MJ_READ UP 0x00000000 3b ;
00051430 2020-06-30 11:25:08,1597592 +0,0000030 IRP_MJ_READ UP 0x00000000 50 P
00051432 2020-06-30 11:25:08,1597662 +0,0000030 IRP_MJ_READ UP 0x00000000 55 U
00051434 2020-06-30 11:25:08,1597732 +0,0000031 IRP_MJ_READ UP 0x00000000 3b ;
00051436 2020-06-30 11:25:08,1597802 +0,0000028 IRP_MJ_READ UP 0x00000000 50 P
00051438 2020-06-30 11:25:08,1597875 +0,0000031 IRP_MJ_READ UP 0x00000000 41 A
00051440 2020-06-30 11:25:08,1597944 +0,0000030 IRP_MJ_READ UP 0x00000000 30 0
00051442 2020-06-30 11:25:08,1598014 +0,0000030 IRP_MJ_READ UP 0x00000000 2c ,
00051444 2020-06-30 11:25:08,1598084 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00051446 2020-06-30 11:25:08,1598154 +0,0000031 IRP_MJ_READ UP 0x00000000 3b ;
00051448 2020-06-30 11:25:08,1598224 +0,0000028 IRP_MJ_READ UP 0x00000000 53 S
00051450 2020-06-30 11:25:08,1598336 +0,0000031 IRP_MJ_READ UP 0x00000000 50 P
00051452 2020-06-30 11:25:08,1598414 +0,0000037 IRP_MJ_READ UP 0x00000000 30 0
00051454 2020-06-30 11:25:08,1598486 +0,0000030 IRP_MJ_READ UP 0x00000000 3b ;
00051456 2020-06-30 11:25:08,6595094 +0,4996568 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051457 2020-06-30 11:25:08,6595264 +0,0000170 IRP_MJ_READ UP 0xc0000120
00051458 2020-06-30 11:25:08,6595351 +0,0000087 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051460 2020-06-30 11:25:10,1654480 +1,5000926 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051461 2020-06-30 11:25:10,1654639 +0,0000159 IRP_MJ_READ UP 0xc0000120
00051462 2020-06-30 11:25:10,1654728 +0,0000089 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051463 2020-06-30 11:25:10,1655307 +0,0000579 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6c 6f 63 0d 0a ++loc..
00051466 2020-06-30 11:25:10,4197040 +0,2530148 IRP_MJ_READ UP 0x00000000 55 U
00051468 2020-06-30 11:25:10,4197602 +0,0000154 IRP_MJ_READ UP 0x00000000 6e n
00051470 2020-06-30 11:25:10,4197697 +0,0000037 IRP_MJ_READ UP 0x00000000 72 r
00051472 2020-06-30 11:25:10,4197769 +0,0000030 IRP_MJ_READ UP 0x00000000 65 e
00051474 2020-06-30 11:25:10,4197842 +0,0000031 IRP_MJ_READ UP 0x00000000 63 c
00051476 2020-06-30 11:25:10,4197915 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00051478 2020-06-30 11:25:10,4197984 +0,0000030 IRP_MJ_READ UP 0x00000000 67 g
00051480 2020-06-30 11:25:10,4198057 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00051482 2020-06-30 11:25:10,4198127 +0,0000031 IRP_MJ_READ UP 0x00000000 69 i
00051484 2020-06-30 11:25:10,4198200 +0,0000031 IRP_MJ_READ UP 0x00000000 7a z
00051486 2020-06-30 11:25:10,4198269 +0,0000030 IRP_MJ_READ UP 0x00000000 65 e
00051488 2020-06-30 11:25:10,4198336 +0,0000028 IRP_MJ_READ UP 0x00000000 64 d
00051490 2020-06-30 11:25:10,4198412 +0,0000034 IRP_MJ_READ UP 0x00000000 20
00051492 2020-06-30 11:25:10,4198484 +0,0000033 IRP_MJ_READ UP 0x00000000 63 c
00051494 2020-06-30 11:25:10,4198554 +0,0000030 IRP_MJ_READ UP 0x00000000 6f o
00051496 2020-06-30 11:25:10,4198627 +0,0000034 IRP_MJ_READ UP 0x00000000 6d m
00051498 2020-06-30 11:25:10,4198697 +0,0000031 IRP_MJ_READ UP 0x00000000 6d m
00051500 2020-06-30 11:25:10,4198767 +0,0000028 IRP_MJ_READ UP 0x00000000 61 a
00051502 2020-06-30 11:25:10,4198836 +0,0000027 IRP_MJ_READ UP 0x00000000 6e n
00051504 2020-06-30 11:25:10,4198909 +0,0000031 IRP_MJ_READ UP 0x00000000 64 d
00051506 2020-06-30 11:25:10,4198982 +0,0000034 IRP_MJ_READ UP 0x00000000 0d .
00051508 2020-06-30 11:25:10,4199052 +0,0000031 IRP_MJ_READ UP 0x00000000 0a .
00051510 2020-06-30 11:25:10,6693790 +0,2494696 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051511 2020-06-30 11:25:10,6693944 +0,0000154 IRP_MJ_READ UP 0xc0000120
00051512 2020-06-30 11:25:10,6694031 +0,0000087 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051514 2020-06-30 11:25:11,1693750 +0,4999524 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051515 2020-06-30 11:25:11,1693904 +0,0000154 IRP_MJ_READ UP 0xc0000120
00051516 2020-06-30 11:25:11,1693985 +0,0000081 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051517 2020-06-30 11:25:11,1694135 +0,0000150 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR DOWN 0x00000000
00051518 2020-06-30 11:25:11,1696798 +0,0002663 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR UP 0x00000000
00051519 2020-06-30 11:25:11,1696926 +0,0000128 IRP_MJ_CLOSE DOWN 0x00000000
00051520 2020-06-30 11:25:11,2738539 +0,1041613 IRP_MJ_CLOSE UP 0x00000000
00051521 2020-06-30 11:25:11,3456136 +0,0717597 IRP_MJ_CREATE - process 36256 () DOWN 0x00000000
00051522 2020-06-30 11:25:11,3686676 +0,0230540 IRP_MJ_CREATE UP 0x00000000
00051523 2020-06-30 11:25:11,3687054 +0,0000378 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00051524 2020-06-30 11:25:11,3696706 +0,0009652 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00051543 2020-06-30 11:25:11,3698544 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00051544 2020-06-30 11:25:11,3706629 +0,0008085 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00051545 2020-06-30 11:25:11,3706704 +0,0000075 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00051546 2020-06-30 11:25:11,3716641 +0,0009937 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00051547 2020-06-30 11:25:11,3716705 +0,0000064 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00051548 2020-06-30 11:25:11,3726941 +0,0010236 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00051549 2020-06-30 11:25:11,3727003 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00051550 2020-06-30 11:25:11,3727034 +0,0000031 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00051551 2020-06-30 11:25:11,3727075 +0,0000041 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 09 00 00 00 80 00 00 00 00 04 00 00 00 04 00 00 ................
00051552 2020-06-30 11:25:11,3746623 +0,0019548 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00051553 2020-06-30 11:25:11,3746706 +0,0000083 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS DOWN 0x00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....................
00051554 2020-06-30 11:25:11,3746737 +0,0000031 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_TIMEOUTS UP 0x00000000
00051573 2020-06-30 11:25:11,3747424 +0,0000055 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE DOWN 0x00000000 00 c2 01 00 ....
00051574 2020-06-30 11:25:11,3756618 +0,0009194 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_BAUD_RATE UP 0x00000000
00051575 2020-06-30 11:25:11,3756685 +0,0000067 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS DOWN 0x00000000
00051576 2020-06-30 11:25:11,3756713 +0,0000028 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_RTS UP 0xc000000d
00051577 2020-06-30 11:25:11,3756780 +0,0000067 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR DOWN 0x00000000
00051578 2020-06-30 11:25:11,3766639 +0,0009859 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_DTR UP 0x00000000
00051579 2020-06-30 11:25:11,3766701 +0,0000062 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL DOWN 0x00000000 00 00 08 ...
00051580 2020-06-30 11:25:11,3776615 +0,0009914 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_LINE_CONTROL UP 0x00000000
00051581 2020-06-30 11:25:11,3776666 +0,0000051 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS DOWN 0x00000000 00 00 00 00 11 13 ......
00051582 2020-06-30 11:25:11,3776691 +0,0000025 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_CHARS UP 0x00000000
00051583 2020-06-30 11:25:11,3776735 +0,0000044 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW DOWN 0x00000000 01 00 00 00 40 00 00 00 00 04 00 00 00 04 00 00 ....@...........
00051584 2020-06-30 11:25:11,3796637 +0,0019902 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_SET_HANDFLOW UP 0x00000000
00051585 2020-06-30 11:25:11,4047401 +0,0250764 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 76 65 72 0d 0a ++ver..
00051588 2020-06-30 11:25:11,6187145 +0,2130000 IRP_MJ_READ UP 0x00000000 41 A
00051590 2020-06-30 11:25:11,6187679 +0,0000168 IRP_MJ_READ UP 0x00000000 52 R
00051592 2020-06-30 11:25:11,6187776 +0,0000036 IRP_MJ_READ UP 0x00000000 34 4
00051594 2020-06-30 11:25:11,6187846 +0,0000030 IRP_MJ_READ UP 0x00000000 38 8
00051596 2020-06-30 11:25:11,6187916 +0,0000031 IRP_MJ_READ UP 0x00000000 38 8
00051598 2020-06-30 11:25:11,6187986 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00051600 2020-06-30 11:25:11,6188053 +0,0000028 IRP_MJ_READ UP 0x00000000 47 G
00051602 2020-06-30 11:25:11,6188123 +0,0000031 IRP_MJ_READ UP 0x00000000 50 P
00051604 2020-06-30 11:25:11,6188190 +0,0000031 IRP_MJ_READ UP 0x00000000 49 I
00051606 2020-06-30 11:25:11,6188257 +0,0000031 IRP_MJ_READ UP 0x00000000 42 B
00051608 2020-06-30 11:25:11,6188327 +0,0000031 IRP_MJ_READ UP 0x00000000 2d -
00051610 2020-06-30 11:25:11,6188397 +0,0000031 IRP_MJ_READ UP 0x00000000 55 U
00051612 2020-06-30 11:25:11,6188475 +0,0000039 IRP_MJ_READ UP 0x00000000 53 S
00051614 2020-06-30 11:25:11,6188550 +0,0000039 IRP_MJ_READ UP 0x00000000 42 B
00051616 2020-06-30 11:25:11,6188617 +0,0000030 IRP_MJ_READ UP 0x00000000 20
00051618 2020-06-30 11:25:11,6188696 +0,0000031 IRP_MJ_READ UP 0x00000000 2c ,
00051620 2020-06-30 11:25:11,6188779 +0,0000044 IRP_MJ_READ UP 0x00000000 20
00051622 2020-06-30 11:25:11,6188846 +0,0000030 IRP_MJ_READ UP 0x00000000 76 v
00051624 2020-06-30 11:25:11,6188916 +0,0000030 IRP_MJ_READ UP 0x00000000 65 e
00051626 2020-06-30 11:25:11,6188983 +0,0000030 IRP_MJ_READ UP 0x00000000 72 r
00051628 2020-06-30 11:25:11,6189050 +0,0000030 IRP_MJ_READ UP 0x00000000 73 s
00051630 2020-06-30 11:25:11,6189120 +0,0000031 IRP_MJ_READ UP 0x00000000 69 i
00051632 2020-06-30 11:25:11,6189187 +0,0000031 IRP_MJ_READ UP 0x00000000 6f o
00051634 2020-06-30 11:25:11,6189257 +0,0000031 IRP_MJ_READ UP 0x00000000 6e n
00051636 2020-06-30 11:25:11,6189324 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00051638 2020-06-30 11:25:11,6189394 +0,0000031 IRP_MJ_READ UP 0x00000000 35 5
00051640 2020-06-30 11:25:11,6189461 +0,0000031 IRP_MJ_READ UP 0x00000000 2e .
00051642 2020-06-30 11:25:11,6189528 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00051644 2020-06-30 11:25:11,6189598 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00051646 2020-06-30 11:25:11,6189665 +0,0000031 IRP_MJ_READ UP 0x00000000 23 #
00051648 2020-06-30 11:25:11,6189735 +0,0000031 IRP_MJ_READ UP 0x00000000 31 1
00051650 2020-06-30 11:25:11,6189802 +0,0000031 IRP_MJ_READ UP 0x00000000 20
00051652 2020-06-30 11:25:11,6189869 +0,0000031 IRP_MJ_READ UP 0x00000000 30 0
00051654 2020-06-30 11:25:11,6189936 +0,0000028 IRP_MJ_READ UP 0x00000000 2e .
00051656 2020-06-30 11:25:11,6190006 +0,0000031 IRP_MJ_READ UP 0x00000000 34 4
00051658 2020-06-30 11:25:11,6190073 +0,0000031 IRP_MJ_READ UP 0x00000000 38 8
00051660 2020-06-30 11:25:11,6190143 +0,0000028 IRP_MJ_READ UP 0x00000000 2e .
00051662 2020-06-30 11:25:11,6190212 +0,0000030 IRP_MJ_READ UP 0x00000000 32 2
00051664 2020-06-30 11:25:11,6190280 +0,0000031 IRP_MJ_READ UP 0x00000000 34 4
00051666 2020-06-30 11:25:11,6190347 +0,0000028 IRP_MJ_READ UP 0x00000000 0d .
00051668 2020-06-30 11:25:11,6190416 +0,0000030 IRP_MJ_READ UP 0x00000000 0a .
00051669 2020-06-30 11:25:11,6190738 +0,0000322 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 73 20 30 0d 0a ++eos 0..
00051671 2020-06-30 11:25:11,6196976 +0,0000168 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6d 6f 64 65 20 30 0d 0a ++mode 0..
00051674 2020-06-30 11:25:12,1205987 +0,4998714 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051675 2020-06-30 11:25:12,1206154 +0,0000167 IRP_MJ_READ UP 0xc0000120
00051676 2020-06-30 11:25:12,1206269 +0,0000115 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051677 2020-06-30 11:25:12,1206506 +0,0000237 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 65 6f 69 20 31 0d 0a ++eoi 1..
00051680 2020-06-30 11:25:13,6655995 +1,4993760 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051681 2020-06-30 11:25:13,6656163 +0,0000168 IRP_MJ_READ UP 0xc0000120
00051682 2020-06-30 11:25:13,6656249 +0,0000086 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051684 2020-06-30 11:25:15,1989184 +1,4998808 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051685 2020-06-30 11:25:15,1989352 +0,0000168 IRP_MJ_READ UP 0xc0000120
00051686 2020-06-30 11:25:15,1989455 +0,0000103 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051688 2020-06-30 11:25:15,7057686 +0,4997750 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051689 2020-06-30 11:25:15,7057848 +0,0000162 IRP_MJ_READ UP 0xc0000120
00051690 2020-06-30 11:25:15,7058002 +0,0000154 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051691 2020-06-30 11:25:15,7058393 +0,0000391 IRP_MJ_WRITE DOWN 0x00000000 2b 2b 6c 6f 63 0d 0a ++loc..
00051694 2020-06-30 11:25:16,2067842 +0,5000356 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE DOWN 0x00000000 02 00 00 00 ....
00051695 2020-06-30 11:25:16,2067999 +0,0000157 IRP_MJ_READ UP 0xc0000120
00051696 2020-06-30 11:25:16,2068091 +0,0000092 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_PURGE UP 0x00000000
00051697 2020-06-30 11:25:16,2068239 +0,0000148 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR DOWN 0x00000000
00051698 2020-06-30 11:25:16,2076877 +0,0008638 IRP_MJ_DEVICECONTROL: IOCTL_SERIAL_CLR_DTR UP 0x00000000
00051699 2020-06-30 11:25:16,2077058 +0,0000181 IRP_MJ_CLOSE DOWN 0x00000000
00051700 2020-06-30 11:25:16,3122482 +0,1045424 IRP_MJ_CLOSE UP 0x00000000
I just came across your project. Where can I find the documentation?
Can you also use your AR488 interface with the Keysight GPIB-VISA drivers? Or do I have to work with the Prologix driver?
I just found your github site and this eevblog.
I have a use case for secondary GPIB addressing - Tektronix 4051/4052/4054 computers used secondary addressing for commands to the devices like external tape, floppy, and hard drives. Here is a list of their primary and secondary addresses from the 4050 BASIC booklet on bitsavers:
(Attachment Link)
I have a 4052 and 4054 and have been thinking they need a GPIB Tape Drive emulator using an SD card - as the 3M DC300 cartridges are hard to find and the drive belts have deteriorated in 40 years.
I think your Device mode GPIB would be able to work as the external Tape Drive (example using GPIB primary address 1), if I can modify your program to get the secondary addresses (tape commands like TLIST, MARK, FIND, OLD, etc) to work.
Does your code allow you to analyze traffic on the GPIB bus?
It won't send anything at all until you hit 'w', and then ++loc will be transmitted when the 'w' operation finishes (meaning a plot arrives or you hit a key to stop waiting.) In principle it shouldn't send ++loc in this case, but Prologix adapters in device mode will ignore it, and all others should as well.
The latest version of the program also does not work.
Only with forced transfer from GPIB Configurator to ++ lon 1 mode does image capture work.
SYNTAX: ++addr [<PAD> [<SAD>]]
where PAD (Primary Address) is a decimal value between 0 and 30.
where SAD (Secondary Address) is a decimal value between 96 and 126. SAD is optional.
MODES AVAILABLE: CONTROLLER, DEVICE
EXAMPLES:
++addr 5 – Set primary address to 5
++addr – Query current address
++addr 9 96 – Set primary address to 9 and secondary address to 0
/*
Tektronix 4924 Tape Emulator device Commands
Principle of operation:
- Listen for 4924 GPIB primary address plus secondary address
- Primary address (My Primary Address - MPA) indicates whether 4924 is talker or listener
- Secondary address (My Secondary Address - MSA) = command
Device Listen commands (assuming Emulator is GPIB device number 5)
MPA MSA Action Data? 4050 BASIC statement
37 12 Print Y - PRINT @5: <variable(s)>
37 15 Print Y - WRITE @5: <binary>
37 1 Print Y - SAVE @5: <binary program in memory>
37 27 Find Y - FIND @5: <file#>
37 28 Mark Y - MARK @5: <# files,size in bytes>
37 7 Kill Y - KILL @5: <file#>
37 29 Secret N - SECRET @5: <mark current file header with Secret flag>
37 2 Close N - PRINT@5,2: <close current file>
37 0 StatIN Y - PRINT@5,0: <w,x,y,z> send tape drive environment parameters
37 9 CD Y - PRINT@5,9: <change directory to path$> **new cmd for EMULATOR**
Device Talk commands (assuming Emulator is GPIB device number 5)
69 13 Input Y - INPUT @5: <variable(s)>
69 14 Input Y - READ @5: <binary variable(s)>
69 4 Input Y - OLD @5: <binary program>
69 0 StatOUT Y - INPUT@5,0: <w,x,y,z> get tape drive environment parameters
69 9 Header Y - INPUT@5,9: <return current file header string>
69 6 Type Y - TYPE @5: <return type of next data in file>
69 19 Tlist Y - TLIST @5: <return header info for every file>
69 30 Error Y - INPUT@5,30: <return error code and clear SRQ>
*/
WaveyDipole,
Yes, I believe the PET used similar syntax to the Tektronix BASIC for GPIB device access.
The Tektronix 4051 computer was introduced in 1975 with a 6800 CPU, 32KB of BASIC ROM and 32KB of DRAM with integrated 1024x768 vector graphics using the same 12" Tektronix direct view storage tube as their 4010 terminal.
I had a think about it and I think I'll just buy some aluminium shielding tape and use that to shield the wires. All I'm trying to do is download the calibration data. I'm not going to use the setup in some demanding RF environment.
BTW, on another topic, I had wondered whether there is any advantage to creating an MQTT enabled version of the AR488? This would use MQTT to configure and control the adapter rather than the Prologix command set and would work over Ethernet and WiFi. Any thoughts?
O@@@BADBECEMML@@@@BACLMLLLH@@@@@BBEDALNEIIIIIDBE@COKE@@@@@@BEMDDNC@@@@@@@@@@@OO@@@@ICCLEDDMG@@@@C@ALNNLLG@@@@@EALAOCMJ@@@@@AALNCLMD@@@@@@ALNNMLI@@@@@@@EEO@NF@@@@@AALMAEMN@@@@@@@EEDAO@@@@AEADNLMOKN@@@@AFDNNMALJ@@@@@@@@@@@OO@@@@ICDOMMOKG@@@@@@@@@@@OO@@@@@@@@
https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/
EDIT: D/L the calibration data for my HP3478A, but it looks wierd. Is there some special software that I need to read it? Notepad shows me this:QuoteO@@@BADBECEMML@@@@BACLMLLLH@@@@@BBEDALNEIIIIIDBE@COKE@@@@@@BEMDDNC@@@@@@@@@@@OO@@@@ICCLEDDMG@@@@C@ALNNLLG@@@@@EALAOCMJ@@@@@AALNCLMD@@@@@@ALNNMLI@@@@@@@EEO@NF@@@@@AALMAEMN@@@@@@@EEDAO@@@@AEADNLMOKN@@@@AFDNNMALJ@@@@@@@@@@@OO@@@@ICDOMMOKG@@@@@@@@@@@OO@@@@@@@@
That doesn't look like anything I've ever seen before that would suggest that the data has integrity. From memory, other peoples calibration data looked different/legible.
#!/bin/sh
if [ -f "$1" ]; then
cat "$1" | od -A x -t x1z -w13 --skip=1 | awk 'BEGIN{
SEP="|";
rectypestr="30 mV DC" SEP "300 mV DC" SEP "3 V DC" SEP "30 V DC" SEP "300 V DC" SEP "<not used>" SEP "AC V" SEP "30 Ohm 2W/4W" SEP "300 Ohm 2W/4W" SEP "3 kOhm 2W/4W" SEP "30 kOhm 2W/4W" SEP "300 kOhm 2W/4W" SEP "3 MOhm 2W/4W" SEP "30 MOhm 2W/4W" SEP "300 mA DC" SEP "3A DC" SEP "<not used>" SEP "300 mA/3A AC" SEP "<not used>" SEP "<padding>";
rectype[0] = "";
split(rectypestr, rectype, SEP);
}{
crc=0;
if(NF==15) {
for(i=1; i<NF; i++)
if(length($i)==2)
crc += strtonum("0x"(substr($i,2))""((i==13)?"0":""));
printf "%s\t// %.2d\tcrc=%x\t%s\n", $0, (NR-1), crc, rectype[NR];
} else if(NF>1) {
printf "%s\t// %.2d\t\t%s\n", $0, (NR-1), rectype[NR];
}
}'
else
echo "$0 <cal file>"
fi
$ ./verify.sh PixieDust.cal
000001 40 40 40 42 41 44 42 45 43 45 4d 4d 4c >@@@BADBECEMML< // 00 crc=ff 30 mV DC
00000e 40 40 40 40 42 41 43 4c 4d 4c 4c 4c 48 >@@@@BACLMLLLH< // 01 crc=ff 300 mV DC
00001b 40 40 40 40 40 42 42 45 44 41 4c 4e 45 >@@@@@BBEDALNE< // 02 crc=ff 3 V DC
000028 49 49 49 49 49 44 42 45 40 43 4f 4b 45 >IIIIIDBE@COKE< // 03 crc=ff 30 V DC
000035 40 40 40 40 40 40 42 45 4d 44 44 4e 43 >@@@@@@BEMDDNC< // 04 crc=ff 300 V DC
000042 40 40 40 40 40 40 40 40 40 40 40 4f 4f >@@@@@@@@@@@OO< // 05 crc=ff <not used>
00004f 40 40 40 40 49 43 43 4c 45 44 44 4d 47 >@@@@ICCLEDDMG< // 06 crc=ff AC V
00005c 40 40 40 40 43 40 41 4c 4e 4e 4c 4c 47 >@@@@C@ALNNLLG< // 07 crc=ff 30 Ohm 2W/4W
000069 40 40 40 40 40 45 41 4c 41 4f 43 4d 4a >@@@@@EALAOCMJ< // 08 crc=ff 300 Ohm 2W/4W
000076 40 40 40 40 40 41 41 4c 4e 43 4c 4d 44 >@@@@@AALNCLMD< // 09 crc=ff 3 kOhm 2W/4W
000083 40 40 40 40 40 40 41 4c 4e 4e 4d 4c 49 >@@@@@@ALNNMLI< // 10 crc=ff 30 kOhm 2W/4W
000090 40 40 40 40 40 40 40 45 45 4f 40 4e 46 >@@@@@@@EEO@NF< // 11 crc=ff 300 kOhm 2W/4W
00009d 40 40 40 40 40 41 41 4c 4d 41 45 4d 4e >@@@@@AALMAEMN< // 12 crc=ff 3 MOhm 2W/4W
0000aa 40 40 40 40 40 40 40 45 45 44 41 4f 40 >@@@@@@@EEDAO@< // 13 crc=ff 30 MOhm 2W/4W
0000b7 40 40 40 41 45 41 44 4e 4c 4d 4f 4b 4e >@@@AEADNLMOKN< // 14 crc=ff 300 mA DC
0000c4 40 40 40 40 41 46 44 4e 4e 4d 41 4c 4a >@@@@AFDNNMALJ< // 15 crc=ff 3A DC
0000d1 40 40 40 40 40 40 40 40 40 40 40 4f 4f >@@@@@@@@@@@OO< // 16 crc=ff <not used>
0000de 40 40 40 40 49 43 44 4f 4d 4d 4f 4b 47 >@@@@ICDOMMOKG< // 17 crc=ff 300 mA/3A AC
0000eb 40 40 40 40 40 40 40 40 40 40 40 4f 4f >@@@@@@@@@@@OO< // 18 crc=ff <not used>
0000f8 40 40 40 40 40 40 40 40 0a >@@@@@@@@.< // 19 <padding>
I'm using an "artag" interface with a modified ++ver string which contains the string: "Xxxxxxxxx GPIB-USB Controller version 6.101". *
I know the communication is OK: using the 'GPIB Configurator' from "KE5FX GPIB Toolkit" I'm able to read and write to my 34410A.
Unluckily the patched version of EZGPIB is unable to identify the AR488 interface: the debugging window reports the following text (COM30 is the AR488 interface):
see attachment, please.....
(https://www.eevblog.com/forum/data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAArMAAAGsCAYAAADOjy/IAAAgAElEQVR4nO3dS4wdxd338dm8et8Fitgg5CyQorwEJfiV4AFnMTxcHALmYoPNJcEQY4fLeBTsByfeZZF4EUYhYeFFErEAMkqEFLEjUiw5YcEikaLISI5YIpHlsEEaASs29S7GZ3ympy7/f9266vT3I5Xi6UtVdXX36R99+nSWTp8+bVzlvvvuM2fOnHGUI+a2PXvMjftPeJa5utyePXvMbUdm006Y/TduTduz5zZzZLbsif3mxh3LecqR28yePTea/Sd2Tj+x/8addR65bdD2lT7duN+ccK0z1+cb958wL7/8snn55ZfN4f/aY/bs+S/z6P/8jzl9+rQ5deqU+cHd/9fs2bPH3HroR2Z1ddWsrKyYx++93Rw+fNjceeed5qWXXmq6nDlzZvt/KRQKhUKhUEqU1LyysrJizpw5Y276f3eYx44fN88995x58cUXzcmTJ83S6dOnDQAAANAbwiwAAAC6RZgFAABAtwizAAAA6BZhFgAAAN0izAIAAKBb0WH2008/Ne+884559dVXzerqqnn66afNuXPnzJtvvmk+/vjjAl0FAAAAdooKs3/5y1/M6uqqef75580rr7xi3njjDfPWW2+Zs2fPmoMHD5oDBw6YV1991XzxxReFug0AAABEhNk//OEPZnV11bz11ltmY2PDfPbZZ+aTTz4xH3/8sfnwww/N+++/b37+85+bu+66yxw/ftx8/vnnBbsPAACAKVOF2dkd2X/84x/myy+/3BVk//nPf5r33nvPvPvuu+ZXv/qV2bdvn/nJT35SeBMAAAAWz9LSkqi0ZmlpyVy6dMk5/9KlS1n7LQ6zn376qVldXTW/+c1vzJdffmn+85//mL///e/mb3/7m/nzn/9s/vSnP5nf//735re//a359a9/bc6dO2eOHj1q9u7da/71r385ar1gVgY7ZPn8R4JuXzArS8tGtGiUK/1auWCd+9H5ZbNUtH0AADB1ksDXYpi9dOmS+V//+/9YA61vXixxmH3nnXfM888/bzY2NsylS5fMs88+a86ePWuOHTtmTp48aX74wx+au+66yywvL5v9+/ebAwcOmOPHj5tbb73VrK6uOmodhlJ/iHSvl9tW/cvLtjZmAZwwCwAAyuk1zBpjD60lgqwxijD76quvmldeecV89tln5ne/+525dOmS+fDDD80vf/nL7UcLlpeXzb59+8yxY8fMuXPnzNmzZ83+/fvNDTfc4KjVEko/Om+Wl1aMP87WCbMrK8u77xRfWDFLKyuF2wcAAFPXc5g1Zmd4LRVkjVGE2dXVVfPGG2+YTz75xPz1r3/dfkb23Llz5t133zVvv/222bdvn7nlllvMk08+ac6ePWtWVlbMnXfeafbs2eOo1RZKPzLnl5fM9s3Zj86b5e3HEGYh98p6F67Ouxo6bXd75/7+aH6d845QOlvnglnZEaw/MueXZ9PtdV7t49Z2zB6f2Noe2zRjLqzMPWoxf1fa11dxmwAAoEe9h1ljrgbaUkHWGEWYffrpp81bb72168dezz33nHn77bfN66+/bm655Razd+9ec/DgQbOysmKOHj1qbr/9dnPdddc5ag2F2cH8CytXQuuVr/qXz5uPjLkS7GbL+cLs1nqzkOd+9vXqOhdWBsF6+bz5aFedlj5eWNn9uIRtmnM8fH1VtAkAALr8MRVhVkYcZmePDQzfWvDMM8+Y119/3bz22mtm79695qabbjL33nuvOXr0qDl48KC5+eabzbXXXuuo1RVmr0zbcfdx/s7l7vWuhk5PmN0Oo7723etY23D18cr0HY8p2KZtdX5ufUFfNW0CAIAu9R5mm3vM4M033zRPPPGEef/9982PfvQj8+Mf/9j84he/MKdOnTKvvfaaOXfunLnpppvM17/+dXPHHXeYgwcPmrvvvttcf/31Znl52VFr4JlZ5/Ozw/U8d3NTw+wsXF+YX3cYLN3P+G7dUd35lf+OaTvWHwR5b5jVtQkAAPrSc5ht8gdgH3/8sTlw4MCutxasra1t37W9+eabzQ033GC++c1vmn379plvfOMb5pprrjF//OMfHbXa32ZwNYRt/b37TuNg+q5AOFfHhZXB1/O6xwyu1uF6LtfVx6s+Or/7h2Tb0y6seB6X8D1moG8TAAD0o9cw2+yruYwx5mc/+5m56667zD333GMef/xx89Of/nQ7yK6srJhHHnnE7N2713zta18zX/3qV80111xjvv3tb3tqHL5n1hIsh1+pzz1msLKybP+x0/zX9sM3D8zNC/8AbLsT5vzy/J1Q3w/ArvRxx6MDV9a1TZv/0dbyillZFvZV2iYAAOhSj8/5GtPw/2mCMcZ88cUX5vjx4+aOO+4wL7zwwo4gO3tG9u677zbf+ta3zFe+8hVz/fXXm3//+9/ZOpud6DVgjeiprwAAAJWowqwxxnz++efmxRdfNHv37jW33nqr2b9/v7nzzjvN7bffbm6++WZz/fXXb9+RbTrImiuvxNrxXGq7euorAABALeowO/Pee++Z1dVVc8MNN5g9e/aY6667zlx77bVmeXnZ84zs2Ha+h7Xtr+J76isAAMA4osMsAAAAMDbCLAAAALpFmAUAAEC3CLMAAADoFmEWAAAA3SLMAgAAoFuEWQAAAHSLMAsAAIBuEWYBAADQLcIsAAAAukWYBQAAQLcIswAAAOgWYRYAAADdkofZy+vm9OnTV8q6ubw10ayfXjMXNwr30lw269ttb5X1y5mb2Lho1rJsS0JfZ2O8dtFs2P4GAADADrIwu3HRrG0H2K2/L142pm6YnWvn8vpcoG7NoK/DsfOuNx98h38DAABgSBZmL6877g6OFGartRsjtq89bSMAAEAbhI8ZbN0lXNuVrK4ErssXzdqVr9R3LLNxdfr81+2X14d3IAd3MnfdjrTcmZ0P1zvamb8LumEurlm+7rcuP2tja50dXZhvz9mWp6/blbkC685HE9YuXhz8vRHs9/r6mjl9en1XbwAAABaZ4gdgV4Ph8Kvwnc94zoesYYC8EuTmA97ldbO2trYd2DYurjlC89xzqDuT5q7wuLX+Vn+dAXzX8nPTdwTQ+fDtWtfT1x2B13f3NXRn1tdv23YCAAAsPv3bDK7cHbSGu/m/Lc+KbofCjYtm7UoAvrx+5c7u2kWzYTbMxTXbV+ueegd3f7fDrutZVdfyu4LlXCi33pW1BWvLmOz4YVlCmBX1GwAAYFqiXs21cXHNEaSEYXY7tM6C4oa5uLZuLs+F3J12trPj7q03tCqmO9oQteWpZ3aHOBj+RWFW8FgDAADAhAh/AHZxVzjb9dX81oKDcDZ8zOBqGNu4uLbr8YL1ddvX9sN67e3sXs/3mIHg8YONi2Ztbd2srw0fEwh9pe+7Mzt4HvfyujmtesxA0G8AAIAJUf0AbPdX65qvxgeBa/heV+97XncHto2La44fZQ37F/oBmOvr+ivPCA8fI3C25Rir4TbNv693fV3xzKy03wAAANPB/wMYAAAAuiUKszt+dDRXAAAAgDFxZxYAAADdIswCAACgW9th9rPPPqNQKBQKhUKhULoq22F2c3OTQqFQKBQKhULpqvCYAQAAAEZDmAUAAEC3CLMAAADoFmEWAAAA3SLMAgAAoFuEWQAAAHSLMAsAAIBu+YLqiRMnCLMAAABoly/IzgphFgAAAE0KBdlQoCXMAgAAYDShO7KhQEuYBQAAwGhcYTY0jTALAACA0Ul/9EWYBQAAQHN4NRcAAAC6RZgFAABAt7KH2aWlpV2lFZr+jN3v1sYuB9uxUWIba4xdyfpd4yMZP9/81PEfriNtI1f7w760bBHPXwBoVdYw6/rwbulDvaW+uPTQx1i2bSsVaHsUGh/p+GnORW2g1fRNskztfdXzf+gAAHarEmZbQh/HRZh1k/S5xzCbs/0cCLMAsFg++OCD6BIVZrVfk7rmzf+trd+1rq0N2zzp+qlf5Urrd/U95qtOyfjH1j1bzzUtx/71tSNZP7T/pPsmtKymz6FlphRmc5+fofna80tbv6Z9yXwAmKKsYdaY8MXAxveBHLpozS8jqT+1T771Uy/UKX2S9jG1L6l1Sy7GKftXOy1Uf459ISUNgyXDvLaP2rCVK4zFnJ+SdSXTQ23E7vOY41PbHgAsouxh1mZ4J0N698MXdnztSPoSW5dv/ZbCbCxJGElpK2YfxUwfK8zO5uUKirH/8RAzVtLzU9KOa5na54h2n4a2X9Jf6bGh3bfS/gHA1FQPs5LlYqZJ6rctQ5j1r0eYHS/M2qaXDLMx9S5amE1pO6Z+bZgFAOxW5ZnZUJjVhomUsFMyzM7+Tr1rQpgdJ8zO/i3Zf6X2RWrgCS1XMszGhvExw6y2/77ltPVo208N4QCwqKo+MxszfzZNsm5oGVu9vmVi1rf1RyPX9qUEacn42/4uuW3SZVLn29qTrp86Pq42QtNj+pfrGKndfq7xL3V+xczXtCEdv5j9CgC9qvKYwZRxUekb+w8AgLYRZjNLveuFcbH/AADoC2EWAAAA3SLMAgAAoFtFwmzoBxSlaOof8yvk0l9la34klNpGTbl+wCRtp6Qa50HMD7Bq/IBsVlfLeMwEAPpR5G0GQ8MLYkmtX4BC45O7fu3fMW3UVHr8StZZQ8z5pxnTWuPvM/XPEADATlXeMztvyheiMfpGmM3XTutizz/CbN36AQB5jRZmpe9h1L5nMfRYg+/r0fnpmv7lfLRB+jWvpj7N39r+pfY/pn3XNEn90n3nm649Pn1j4Fo3tKymz6FlaobZ3OdfaL72+NPWr2lfMh8AoDdKmB1eYGz/Hq4jmS+tL1SXpj7thTxmvq0PkjGR9DfmYhoTAH19iw1DklA0X39qQIs5PnOMlZTm/CsV5lP7Kjk2Sh9/sWOe4/MLAKA3+mMGrjsntgumpv4cwdHWP2k9mjY1fZKGWVedrYTZWDHHWMz0scLsbF5MUPTdBZS0K+lf6jmgrV87pr7PD2l/pftGO7bS/gEAdJoLs5p1XctILhCEWVmfYvuZu03NuoRZ9/RFD7MpbcfUn/vzCwCgt7m5mVSS32YguRiEgpurjlBgkEz33e3KFThits+1TurfEoRZ93Tp8VFqrFIDV2i51sKs5vMjtJy2Hm37qSEcAGCXPcwas/uCbptu+9u2riZM+pbXrO/r31DshTx1+4Z9dNURaj9n36X9T/kPgdi2pcukzre1J10/5vhztSkZf8m6of2X2rfY7S91/MXM17SROn4AgN2KhNkp4WIEH44PAADKIswqcVcFPhwfAADURZgFAABAtwizAAAA6FbWMJvjByIljd2fsdtfNIwnAACo/mquHFLqGzv8jN3+omE8AQCYNsJsZWO3v2gYTwAApq16mI15z+SwrpRHGHx1S+ov+Z7N1PmhsUvtn+QxktT+8Z5OAACgUSTM+sKMjSuw+ObHkvbJNl/af2l9w2mh+iXta7cv1Ddb/aX6F7P9hFkAAKatyp3Z0DxtWM35mEHKndEc7c9Pc935lM6XbJ+2b8PpKf0P9U+y/dI+AwCAaSDMCoOaqy5tX2LubEr64lqmhTuz0v7FbD9hFgCAaes+zKaGSU2Y7eUxg5x9C9Wfs388ZgAAALSKvmfWJvQVtKSO+WU1fF/bu/owmxbTR1/7rvVT5ku2L6aPNfsXUz+BFgCA6cp+ZxaLjeAIAABaQpiFGHdCAQBAawizAAAA6BZhFgAAAN0qEman8lV07HZqfgCX8iO5XP3NZez2tXrrr9aibx8AYBqK3Zlt+SKZs28xb1RwTXO9psr3aiptH8beL2O3rxX7HysljXn8AgDQGsJsxbpSl83R77H3y9jtaxFmAQBoW7HHDOb/dziv9ntMfevn7p9PS2FWuv2h+TF3pkvvf9/21e5fb/UDANCbqmHWdeH0hV/N/Pm/hyFH0w9N+zXD7Gx6jjAp7ZNk2VwhPcf+126ftG/S9jXLDaePUT9hFgDQu+xhNnThDYUw7V0n190nH01QHN7tk9alaXfMZVPuDMYIhdnQ+If2v/ZYkPZN2r6vzZjjS9rP2PoJswCA3hUJs9I7h9r5qRf70PyY9VoMqJplQ+Obsv8k7c9Pi91vvmVyh9nYeiTrj1E/YRYA0Luqd2ZDF+HU+aF2Qn2KaT9nmIuZpu1DSpgt0f78tBz7f4wwKx3TEsd37eMXAIDWZA2ztq81bXdXQ1/Rxs7PcVc4pv2YQOtbVzpP23bM/plNy91+6f3v2r7UPkq3P+fxVbp+Ai0AoGfFXs0FAAAAlEaYBQAAQLcIswAAAOgWYRYAAADdGvXVXKn48YodP+zZwhgAALD4sr/NwKZ0oO1NzfHocXxymvr2AwCw6KqE2ZJi2wyt12sAJ8zuNPXtBwBg0VUPs5J3eA7/LV1fIzbMSt7h6fo7tL5tvnb7UsNs7ve8utZ19U06vqWPDwAA0Ieqz8xKHkPwreMKLzFy3ZkNhUdNn3M8ppESZkPtS/efb53Q/FCfah0fAACgD1XeZjC8m6YJvDnDSqh9af9Cdw9D/estzIbm5wyzKeNLmAUAYHqqh9mQWmElJrhJphFm48Ns6vgSZgEAmJ6qbzPQhCHJPF+dITXCrO3Oom2ZUJ/GDrO1HjMgzAIAAK3q75mVfoVv+9u1fkxgSbkLaeunbZnhv13L+OqP3bYc68buv9m/bdN8823125atcXwAAIA+VHnMAAAAACiBMAsAAIBuEWYBAADQLcIsAAAAulX9B2A58eOevrH/AABAqqqv5iqBMNQ39h8AAEhRJcyWVPM9s8iPcQYAACmqh1nNe0pLvYdV0tdQ27a/pdsX2sZQv1LfAxt6P65rvq1+2zzftvEOWAAAkFPVZ2YljyH41nGFoxixd2ZtAS5mHcl62j5Jx9e3Tmh+qE+19h8AAIAxld5mYLuTKQ28OcNQqP0c/Qutr+2zZr0aYVa7bYRZAABQUvUwG1IrDMUGw/l5sSG11zArGX/CLAAAqKnq2ww0YUsyz1dnSM0wW/rObK3HDAizAACgNdXfMxv6Ct/1tb9v/ZhAlBJmffOl25fS79Txne+/bbxd823125atsf8AAACM4f8BDAAAAB0jzAIAAKBbhFkAAAB0izALAACAbmV/m0ErP+6p0S4/XgIAABhXkbcZDC1y4FvkbQMAAGgdYTbRIm8bAABA66qH2ZT3pGrn2/oR8x5UTfshkrqH/5a2n7p9rvVd2wEAADC2ImHWF5Zshi/fj50fmmabntq/1FDnC7Ta/rnq06wf6gMAAEBLit6ZldzVHN4J9AmtP1zWVYfr75j+pd6Z9fXH9bfkjqmtz9LxI7wCAIBeVA+zPqnzpcu6wmlM+6l90obZ4TzX8q4wG9tPAACAFhV/Zra1xwx89ZV+zCA1zGrvNmu3L7QcAABAa4q9Z3bG9bfvK+6S8+eXc03X1q8NtK7HF2zTteM3rE+zfZrtIvACAIAWZL8zCwAAANRCmAUAAEC3CLMAAADoFmEWAAAA3Sr2A7DYH0jlNGbbPpK3M0h/oKX5AVzOH6/Z/s7Vfmh8pH1FXrXO7Rrnbcn6Wz1/h+20rNXP7pYs+hj1tn2a/va0Xb0o/mou17RaWjxoQm8b8E2LWSd2Wcn6ob5JlnHV2eK+m7pa53ev+7718zeHnv9DowU5ty+mrp72X4vHgq9PLfY3t1a3sUqYHVNr/TFG/x7Y0DKth1lt+4TZdhFm3Xo4f3PoKQy1aOyw19P+a/FYIMy2uY1Fw6zrgzf0NZrkb9ct/ZSv4UrXL2k/ZplFC7MpfPtFsn819dvGIuX4GU4LLSNdPyff/pO0Lz1/fNMl+0A6Rq51Q8tq+hxapvb5m3J+hPZd6vGprV/TvmS+T+r5Lem/tA+x21d6/MbcP6H1JftPW79tvq/+0HblOD5jxzfH+TmmImHWN5A2wwH1rWPbAb76Y08Gaf0xbfjaliwjOaBKnCy2elM/7EqdEKHtDy0X207q8eMbX+m+zr2NtrolF6xh+5pjVXMu++qPOT8ky2nqHC4z5vkrrd+3XI4x1Xzm+2jOjxyf3zmuDzn3Wc72c41fzvpznH/DMUr9bPStI60/x3mlrXeM87OmqndmUy/mob9TT4aY+mPa0LQde/LFnES2C2WOAzv3PpIodWEJhQnJ35IQY/sAkuyfmG3S0O7v2OkxH/a5LhCxQXHs81cj5fzwrZvj+JTuG+3YSvun6VvM9SH2/Azti9TxD62f49jV1p+yb2zTc+yL0PGp7dNwesxnj6/e0P7LeX6OqeozszkONu2HSY4LUqiuXDs3ZnxS6tLWaVtWG25yXYw1bfqmp35Yao/X4TzX8rYPoNR9n4N2f8dO14ao2HVc82IuKD2cv9r6c42pZrnYba9xEW49zMbWI1l/jPqnFmaHy+T4DCLMNhBmfRf70LqS/kj6WDPMuupq6WKYOj5TDrPaPsV+ME41zM7+PSwpfcl5MdHU10uYLRHmcodZ7cVc07fU7c/5+ZPafq7xy1l/62FW8/kfml7i+JyfVuL8bCnYFn3PrI3kYjM/3fZv19+u+jUXkJj6c3PVnzq+KWPjamOM9qV987Uf2g5p/bNp0vqlx//8/8ZsX2i7Uve7tm/SZVLnh7az9PFhayM0PaZ/ufoWu/25zv/Q+pL5mjZSxi/X+T2/nFboGEhtP9f45aw/dh+VOr9d25fj+Ch5fofma9qOHbeSst+ZBdC21j6ESprStgKYtil/3hFmASyMlLsaANCrqX/uEWYBAADQLcIsAAAAulUkzIYeMC5FU/+Yt+JLfxWao+4xvq5Iffhf205JNY5zyQP8qT8AiN2O1r/qmvLXcQCwaKq8mmt4wSyp9QtUaHxy1x/7S82xlB6fknXWEHN+aca01vj7TP0zAgCgk/3VXCFTvlCN0TfCrLyd1sWeX4TZuvUDAOoaLcy6vuZL+Zp02IfQ+q62tf3L+WiD9GtgTX0aoe3S9i+mfdc0Sf3SfeObrj3+fGPgWje0rKbPoWVqhtnc51dovvb409avaV8yHwCQ3yhhdngBsv17uI5kvrS+UF2a+rQX+pj5tj5IAm3shTQmAA7/lu4HW13SQDGsPzWgxRx/OcZKSnN+lQrzqX2VHBulj7/YMc/x+QQAyG/0xwxcd1ZsF1RN/TmCo61/0no0bWr6JA2zKRfQmgFN2kZMP3zTxwqzs3kxQdF3F1DSrqR/qce4tn7tmPo+H6T9le4b7dhK+wcAyKu5MKtZ17WM5AKyyGE29eJJmLVPby3M2qYvephNaTum/tyfTwCA/EZ/m4HkYqG5Cym9+MRebFPvuvjGJ0eYzXFBJcy6p0v3f6mxSg1coeVaC7Oaz4fQctp6tO2nhnAAQJxR3jM7/+HvW8YWFnzzfctr1vf1byj2Qp+6fcM+StZP7Zu0f2O0LV0mdb6tPen6MceXq03J+EvWDe2/1L7Fbn+p4y9mvqaN1PEDAOgVCbNTwsVq2tj/AACMizCrxF2XaWP/AwDQFsIsAAAAukWYBQAAQLeyv5qr5R9AjN2fsdtfNIwnAACo/mquHFLqGzv8jN3+omE8AQCYNsJsZWO3v2gYTwAApq16mI15D+WwrpRHGHx1S+ov+R7O1PmhsUvtn+QxktT+8R5PAACgUSTM+sKMjSuw+ObHkvbJNl/af2l9w2mh+iXta7cv1Ddb/aX6F7P9hFkAAKatyp3Z0DxtWM35mEHKndEc7c9Pc935lM6XbJ+2b8PpKf0P9U+y/dI+AwCAaSDMCoOaqy5tX2LubEr64lqmhTuz0v7FbD9hFgCAaes+zKaGSU2Y7eUxg5x9C9Wfs388ZgAAALSKvmfWJvQVtKSO+WU1fF/bu/owmxbTR1/7rvVT5ku2L6aPNfsXUz+BFgCA6cp+ZxaLjeAIAABaQpiFGHdCAQBAawizAAAA6BZhFgAAAN0qEman8lV07HZqfgCX8iO5XP3NZez2tXrrr9aibx8AYBqK3Zlt+SKZs28xb1RwTXO9psr3aiptH8beL2O3rxX7HysljXn8AgDQGsJsxbpSl83R77H3y9jtaxFmAQBoW7HHDOb/dziv9ntMfevn7p9PS2FWuv2h+TF3pkvvf9/21e5fb/UDANCbqmHWdeH0hV/N/Pm/hyFH0w9N+zXD7Gx6jjAp7ZNk2VwhPcf+126ftG/S9jXLDaePUT9hFgDQu+xhNnThDYUw7V0n190nH01QHN7tk9alaXfMZVPuDMYIhdnQ+If2v/ZYkPZN2r6vzZjjS9rP2PoJswCA3hUJs9I7h9r5qRf70PyY9VoMqJplQ+Obsv8k7c9Pi91vvmVyh9nYeiTrj1E/YRYA0Luqd2ZDF+HU+aF2Qn2KaT9nmIuZpu1DSpgt0f78tBz7f4wwKx3TEsd37eMXAIDWZA2ztq81bXdXQ1/Rxs7PcVc4pv2YQOtbVzpP23bM/plNy91+6f3v2r7UPkq3P+fxVbp+Ai0AoGfFXs0FAAAAlEaYBQAAQLcIswAAAOgWYRYAAADdGvXVXKn48YodP+zZwhgAALD4sr/NwKZ0oO1NzfHocXxymvr2AwCw6KqE2ZJi2wyt12sAJ8zuNPXtBwBg0VUPs5J3eA7/LV1fIzbMSt7h6fo7tL5tvnb7UsNs7ve8utZ19U06vqWPDwAA0Ieqz8xKHkPwreMKLzFy3ZkNhUdNn3M8ppESZkPtS/efb53Q/FCfah0fAACgD1XeZjC8m6YJvDnDSqh9af9Cdw9D/estzIbm5wyzKeNLmAUAYHqqh9mQWmElJrhJphFm48Ns6vgSZgEAmJ6qbzPQhCHJPF+dITXCrO3Oom2ZUJ/GDrO1HjMgzAIAAK3q75mVfoVv+9u1fkxgSbkLaeunbZnhv13L+OqP3bYc68buv9m/bdN8823125atcXwAAIA+VHnMAAAAACiBMAsAAIBuEWYBAADQLcIsAAAAulX9B2A58eOevrH/AABAqtQwe88998hfzVUCYahv7D8AAJAiNcw+99xz4TBbUs33zCI/xhkAALjPm2EAABkfSURBVKSoHmY17ykt9R5WSV9Dbdv+lm5faBtD/Up9D2zo/biu+bb6bfN828Y7YAEAQE5Zw6wx4TBl4wq0tnm+dTVi78zaAlzMOpL1tH2Sjq9vndD8UJ9q7T8AAABjCoRZG9udTGngzRmGQu3n6F9ofW2fNevVCLPabSPMAgCAkqqH2ZBaYSg2GM7Piw2pvYZZyfgTZgEAQE1VnpmN+RpcMs9XZ0jNMFv6zmytxwwIswAAoDWpYfbYsWO698yGvsJ3fe3vWz8mEKWEWd986fal9Dt1fOf7bxtv13xb/bZla+w/AAAAY9LD7AsvvMD/AxgAAADGQZgFAABAtwizAAAA6BZhFgAAAN3KGmZb+nFPjXb58RIAAMC4st+ZndrrlxZ52wAAAFpHmE20yNsGAADQuuphNuU9qdr5tn7EvAdV036IpO7hv6Xtp26fa33XdgAAAIytSJj1hSWb4cv3Y+eHptmmp/YvNdT5Aq22f676NOuH+gAAANCSondmJXc1h3cCfULrD5d11eH6O6Z/qXdmff1x/S25Y2rrs3T8CK8AAKAX1cOsT+p86bKucBrTfmqftGF2OM+1vCvMxvYTAACgRcWfmW3tMQNffaUfM0gNs9q7zdrtCy0HAADQmmLvmZ1x/e37irvk/PnlXNO19WsDrevxBdt07fgN69Nsn2a7CLwAAKAF2e/MAgAAALUQZgEAANAtwiwAAAC6RZgFAABAt4r9ACz2B1I5jdm2j+TtDNIfaGl+AJfzx2u2v3O1HxofaV+RV61zu8Z5W7L+Vs/fYTsta/WzuyWLPka9bZ+mvz1tVy+Kv5rLNa2WFg+a0NsGfNNi1oldVrJ+qG+SZVx1trjvpq7W+d3rvm/9/M2h5//QaEHO7Yupq6f91+Kx4OtTi/3NrdVtrBJmx9Raf4zRvwc2tEzrYVbbPmG2XYRZtx7O3xx6CkMtGjvs9bT/WjwWCLNtbmPRMOv64A19jSb523VLP+VruNL1S9qPWWbRwmwK336R7F9N/baxSDl+htNCy0jXz8m3/yTtS88f33TJPpCOkWvd0LKaPoeWqX3+ppwfoX2Xenxq69e0L5nvk3p+S/ov7UPs9pUevzH3T2h9yf7T1m+b76s/tF05js/Y8c1xfo6pSJj1DaTNcEB969h2gK/+2JNBWn9MG762JctIDqgSJ4ut3tQPu1InRGj7Q8vFtpN6/PjGV7qvc2+jrW7JBWvYvuZY1ZzLvvpjzg/Jcpo6h8uMef5K6/ctl2NMNZ/5PprzI8fnd47rQ859lrP9XOOXs/4c599wjFI/G33rSOvPcV5p6x3j/Kyp6p3Z1It56O/UkyGm/pg2NG3HnnwxJ5HtQpnjwM69jyRKXVhCYULytyTE2D6AJPsnZps0tPs7dnrMh32uC0RsUBz7/NVIOT986+Y4PqX7Rju20v5p+hZzfYg9P0P7InX8Q+vnOHa19afsG9v0HPsidHxq+zScHvPZ46s3tP9ynp9jqvrMbI6DTfthkuOCFKor186NGZ+UurR12pbVhptcF2NNm77pqR+W2uN1OM+1vO0DKHXf56Dd37HTtSEqdh3XvJgLSg/nr7b+XGOqWS5222tchFsPs7H1SNYfo/6phdnhMjk+gwizDYRZ38U+tK6kP5I+1gyzrrpauhimjs+Uw6y2T7EfjFMNs7N/D0tKX3JeTDT19RJmS4S53GFWezHX9C11+3N+/qS2n2v8ctbfepjVfP6Hppc4PuenlTg/Wwq2Rd8zayO52MxPt/3b9berfs0FJKb+3Fz1p45vyti42hijfWnffO2HtkNa/2yatH7p8T//vzHbF9qu1P2u7Zt0mdT5oe0sfXzY2ghNj+lfrr7Fbn+u8z+0vmS+po2U8ct1fs8vpxU6BlLbzzV+OeuP3Uelzm/X9uU4Pkqe36H5mrZjx62k7HdmAbSttQ+hkqa0rQCmbcqfd4RZAAsj5a4GAPRq6p97hFkAAAB0izALAACAbhUJs6EHjEvR1D/mrfgaX4Wm1jvG1xWpD/9r2ympxnEueYA/9QcAsdvR+lddU/46DgAWTZVXcw0vmCW1foEKjU+O+lMv1GMHfcm0Eu30IOb80oxprfH3mfpnBABAJ/uruUKmfKGq2TfCrL6d1sWeX4TZuvUDAOoaLcy67h6mfE067ENofVfb2v7lfLRB+jVwqL6Ur4clYyTtn7YfvjAlqV+6b3zTtcefbwxc64aW1fQ5tEzNMJv7/ArN1x5/2vo17UvmAwDyGyXMDi9Atn8P15HMl9YXqktTn/ZCHzPf1gfNmGjFBMDh39L9YKtLGiiG9acGtJjjL8dYSWnOr1JhPrWvkmOj9PEXO+Y5Pp8AAPmN/piB686K7YKqqT9HcLT1T1qPpk1Nn3oJs7nbjumHb/pYYXY2LyYo+u4CStqV9C/1GNfWrx1T3+eDtL/SfaMdW2n/AAB5NRdmNeu6lpFcQAizaf3wTSfM1gmztumLHmZT2o6pP/fnEwAgv9HfZiC5WGiCm/TiE3uxTb3r4hsfwmzbYXb2b8n+LzVWqYErtFxrYVbz+RBaTluPtv0S5yIAIGyU98zOf/j7lrGFBd983/Ka9X39G4q90Kdu37CPkvVT+ybt3xhtS5dJnW9rT7p+zPHlalMy/pJ1Q/svtW+x21/q+IuZr2kjdfwAAHpFwuyUcLGaNvY/AADjIswqcddl2tj/AAC0hTALAACAbhFmAQAA0K3sr+Zq+QcQY/dn7PYXDeMJAACqv5orh5T6xg4/Y7e/aBhPAACmjTBb2djtLxrGEwCAaaseZmPeQzmsK+URBl/dkvpLvoczdX5o7FL7J3mMJLV/vMcTAABoFAmzvjBj4wosvvmxpH2yzZf2X1rfcFqofkn72u0L9c1Wf6n+xWw/YRYAgGmrcmc2NE8bVnM+ZpByZzRH+/PTXHc+pfMl26ft23B6Sv9D/ZNsv7TPAABgGgizwqDmqkvbl5g7m5K+uJZp4c6stH8x20+YBQBg2roPs6lhUhNme3nMIGffQvXn7B+PGQAAAK2i75m1CX0FLaljflkN39f2rj7MpsX00de+a/2U+ZLti+ljzf7F1E+gBQBgurLfmcViIzgCAICWEGYhxp1QAADQGsIsAAAAukWYBQAAQLeKhNmpfBUdu52aH8Cl/EguV39zGbt9rd76q7Xo2wcAmIZid2Zbvkjm7FvMGxVc01yvqfK9mkrbh7H3y9jta8X+x0pJYx6/AAC0hjBbsa7UZXP0e+z9Mnb7WoRZAADaVuwxg/n/Hc6r/R5T3/q5++fTUpiVbn9ofsyd6dL737d9tfvXW/0AAPSmaph1XTh94Vczf/7vYcjR9EPTfs0wO5ueI0xK+yRZNldIz7H/tdsn7Zu0fc1yw+lj1E+YBQD0LnuYDV14QyFMe9fJdffJRxMUh3f7pHVp2h1z2ZQ7gzFCYTY0/qH9rz0WpH2Ttu9rM+b4kvYztn7CLACgd0XCrPTOoXZ+6sU+ND9mvRYDqmbZ0Pim7D9J+/PTYvebb5ncYTa2Hsn6Y9RPmAUA9K7qndnQRTh1fqidUJ9i2s8Z5mKmafuQEmZLtD8/Lcf+HyPMSse0xPFd+/gFAKA1WcOs7WtN293V0Fe0sfNz3BWOaT8m0PrWlc7Tth2zf2bTcrdfev+7ti+1j9Ltz3l8la6fQAsA6FmxV3MBAAAApRFmAQAA0C3CLAAAALpFmAUAAEC3Rn01Vyp+vGLHD3u2MAYAACy+7G8zsCkdaHtTczx6HJ+cpr79AAAsuiphtqTYNkPr9RrACbM7TX37AQBYdNXDrOQdnsN/S9fXiA2zknd4uv4OrW+br92+1DCb+z2vrnVdfZOOb+njAwAA9KHqM7OSxxB867jCS4xcd2ZD4VHT5xyPaaSE2VD70v3nWyc0P9SnWscHAADoQ5W3GQzvpmkCb86wEmpf2r/Q3cNQ/3oLs6H5OcNsyvgSZgEAmJ7qYTakVliJCW6SaYTZ+DCbOr6EWQAApqfq2ww0YUgyz1dnSI0wa7uzaFsm1Kexw2ytxwwIswAAQKv6e2alX+Hb/natHxNYUu5C2vppW2b4b9cyvvpjty3HurH7b/Zv2zTffFv9tmVrHB8AAKAPVR4zAAAAAEogzAIAAKBbhFkAAAB0izALAACAblX/AVhO/Linb+w/AACQquqruUogDPWN/QcAAFJUCbMl1XzPLPJjnAEAQIrqYVbzntJS72GV9DXUtu1v6faFtjHUr9T3wIbej+uab6vfNs+3bbwDFgAA5FT1mVnJYwi+dVzhKEbsnVlbgItZR7Ketk/S8fWtE5of6lOt/QcAAGBMpbcZ2O5kSgNvzjAUaj9H/0Lra/usWa9GmNVuG2EWAACUVD3MhtQKQ7HBcH5ebEjtNcxKxp8wCwAAaqr6NgNN2JLM89UZUjPMlr4zW+sxA8IsAABoTfX3zIa+wnd97e9bPyYQpYRZ33zp9qX0O3V85/tvG2/XfFv9tmVr7D8AAABj+H8AAwAAQMcIswAAAOgWYRYAAADdIswCAACgW9nfZtDKj3tqtMuPlwAAAMZV5G0GQ4sc+BZ52wAAAFpHmE20yNsGAADQuuphNuU9qdr5tn7EvAdV036IpO7hv6Xtp26fa33XdgAAAIytSJj1hSWb4cv3Y+eHptmmp/YvNdT5Aq22f676NOuH+gAAANCSondmJXc1h3cCfULrD5d11eH6O6Z/qXdmff1x/S25Y2rrs3T8CK8AAKAX1cOsT+p86bKucBrTfmqftGF2OM+1vCvMxvYTAACgRcWfmW3tMQNffaUfM0gNs9q7zdrtCy0HAADQmmLvmZ1x/e37irvk/PnlXNO19WsDrevxBdt07fgN69Nsn2a7CLwAAKAF2e/MAgAAALUQZgEAANAtwiwAAAC6RZgFAABAt4r9ACz2B1I5jdm2j+TtDNIfaGl+AJfzx2u2v3O1HxofaV+RV61zu8Z5W7L+Vs/fYTsta/WzuyWLPka9bZ+mvz1tVy+Kv5rLNa2WFg+a0NsGfNNi1oldVrJ+qG+SZVx1trjvpq7W+d3rvm/9/M2h5//QaEHO7Yupq6f91+Kx4OtTi/3NrdVtrBJmx9Raf4zRvwc2tEzrYVbbPmG2XYRZtx7O3xx6CkMtGjvs9bT/WjwWCLNtbmPRMOv64A19jSb523VLP+VruNL1S9qPWWbRwmwK336R7F9N/baxSDl+htNCy0jXz8m3/yTtS88f33TJPpCOkWvd0LKaPoeWqX3+ppwfoX2Xenxq69e0L5nvk3p+S/ov7UPs9pUevzH3T2h9yf7T1m+b76s/tF05js/Y8c1xfo6pSJj1DaTNcEB969h2gK/+2JNBWn9MG762JctIDqgSJ4ut3tQPu1InRGj7Q8vFtpN6/PjGV7qvc2+jrW7JBWvYvuZY1ZzLvvpjzg/Jcpo6h8uMef5K6/ctl2NMNZ/5PprzI8fnd47rQ859lrP9XOOXs/4c599wjFI/G33rSOvPcV5p6x3j/Kyp6p3Z1It56O/UkyGm/pg2NG3HnnwxJ5HtQpnjwM69jyRKXVhCYULytyTE2D6AJPsnZps0tPs7dnrMh32uC0RsUBz7/NVIOT986+Y4PqX7Rju20v5p+hZzfYg9P0P7InX8Q+vnOHa19afsG9v0HPsidHxq+zScHvPZ46s3tP9ynp9jqvrMbI6DTfthkuOCFKor186NGZ+UurR12pbVhptcF2NNm77pqR+W2uN1OM+1vO0DKHXf56Dd37HTtSEqdh3XvJgLSg/nr7b+XGOqWS5222tchFsPs7H1SNYfo/6phdnhMjk+gwizDYRZ38U+tK6kP5I+1gyzrrpauhimjs+Uw6y2T7EfjFMNs7N/D0tKX3JeTDT19RJmS4S53GFWezHX9C11+3N+/qS2n2v8ctbfepjVfP6Hppc4PuenlTg/Wwq2Rd8zayO52MxPt/3b9berfs0FJKb+3Fz1p45vyti42hijfWnffO2HtkNa/2yatH7p8T//vzHbF9qu1P2u7Zt0mdT5oe0sfXzY2ghNj+lfrr7Fbn+u8z+0vmS+po2U8ct1fs8vpxU6BlLbzzV+OeuP3Uelzm/X9uU4Pkqe36H5mrZjx62k7HdmAbSttQ+hkqa0rQCmbcqfd4RZAAsj5a4GAPRq6p97hFkAAAB0izALAACAbhX5AdhM7tveqQ+Ha9spqWT9mge8Ux8Qj92O1r8KafHrmrH7NHb7Gi30tYU+AMAUFH81V+4Pc9cvJHPr9SIUGh/p+Pl+pSpdtpSe/0Mj1dh9G7t9iZb62FJfsIV9AiyeImE2FJ5SEGbdJH0mzI5ff4qx+zZ2+xIt9bGlvmAL+wRYPNXDbI73qLmmDevUfo0eakeyfuireF+7rv5Lx6iHMCvZ/uG/XetL5vvGXrL/crYvmR9Scnyk7adsn2T/+LZP2z9N/zV/jzG+qeMj+XzJMT65+iitX9p/2/zU9gG0IUuYPXXq1HaFwxN9+GFgo/lQkFwsbB9C2val00L1a7fZ9uErJVlWerH1TU+5WEvr9y2XY0x9bcSOeczxEdOepM2Y/knbd03Lsf3a7ZP2UdO+bx1f/zTHakr/UsbHt305xielj6ntp36maton0AJtyRJmjx8/vl1hzAdvicCWOn2sMDubFxMUXRfeUhcWbZ0x9WvH1FU0/ZXum5hgKemfpm++fe7a9phjy9Xe/LTQ9km2X7uvpH2UTpeMr3RdX5ul+qdto1SYjRU6PjXHv6+NUNuh45MwC7QlNcw+9dRTZunkyZPbFRJm0/oym5cjzNqmL3qYTWk7pn5tmE2VM0zlOsakF/aYc5cwmzfMzq8jratmmB3Wk3q85f78IMwCbUoNsydOnDBLZ86c2a4w9b/8Q1oOs7N/u/6rPqYvOcOGpr5ewmzM8VU7zIYufCnHvyZMlTr/pNtXO6zFTLedy746phxmtWFR2q/Q9JT+D//Wnh+EWaBNqWH25MmTV8OsLcDZPkgkYc8mtJ6k7tAyqfNt7UnXH06LGSNbG6HpMf3L1bfY7Y/ZvzHHh2S+po1cx7/t7xz9k7Zf4vzJcfxr91/o2PL1p8Q5Unp85uvStj9cxvXv1H5J6kjp/7Df0vVt55SvHgD1ZA2z2I0PNQCt6f1zqff+A8iLMJtZ6p0JACil98+l3vsPoAzCLAAAALpFmAUAAEC3CLMAAADoFmEWAAAA3SLMAgAAoFuEWQAAAHSLMAsAAIBuEWYBAADQLcIsAAAAukWYBQAAQLcIswAAAOgWYRYAAADdIswCAACgW4RZAAAAdIswCwAAgG4RZgEAANAtwiwAAAC6RZgFAABAt4bh9MSJE9bQ6pp+8uRJs3TP/YfG3g4AAABMkC20DoOrbdqs/Pd3HjBL+w88MvZ2AAAAYIJcYXYWXod/D8ud9z5ImAUAAMA4XI8UDIvrmVnCLAAAAEbjCqmSIEuYBQAAwKh8QTUUZLfD7HceeHTs7QAAAMAEpb6a6657HyLMAgAAYBx5wuyDh8feDgAAAExQcpj97kNm6V7CLAAAAEaQGmbvvu9hwiwAAADGkSXMfvehI2NvBwAAACYmNchubm6ae2ZhNkdlH3zwQXLJ0Q8KhUKhUCgUyjTKPfcfNEv3PfxYlsoIsxQKhUKhUCiUmmX//YcIsxQKhUKhUCiUPsv++w+ZpfsPPp6lMsIshUKhUCgUCqVm+c6BQ2bp/kPhMCv5/8clzFIoFAqFQqFMu0gyY87ynQceMUsHDj2RpVOEWQqFQqFQKBRKzUB77wOPmqUDj7jDrKYzhFkKhUKhUCgUyuZmvUB774OPmqUHHnkySycIsxQKhUKhUCiUWakRaL/74GGz9MCj9jCr7QRhlkKhUCgUCoWyuVnvzux3Hzpslh589HtZOkOYpVAoFAqFQqHUfGb2voePmKWHDn8/S6cIsxQKhUKhUCjTLrXfZnD/w4+ZpYeOhMOspBBmKRQKhUKhUCg1y4GDj5ulh488laUywiyFQqFQKBQKpWY5cOhxs/TwY4RZCoVCoVAoFEp/5YFHnjBLBx87mqUywiyFQqFQKBQKpWZ58NEnzdKhx/OEWQqFQqFQKBQKpWZ56PD3zNKhx58evSMUCoVCoVAoFIq2PHzkKbP0yBPPjN4RCoVCoVAoFApFWw4+dnQrzK6vr1MoFAqFQqFQKN0UY4w59PjTZunRJ39g1tfXR0/WFAqFQqFQKBSKpjzyxDOEWQqFQqFQKBRKn+XRJ39glg5/7xhhlkKhUCgUCoXSXSHMUigUCoVCoVC6K8YYs7m5aQ5/7xhhlkKhUCgUCoXSTzHGbGdXwiyFQqFQKBQKpZsyC7I7wuyR7z9LmKVQKBQKhUKhNF2GQXZzc9Mc+f6zhFkKhUKhUCgUSttlGGRnz8we+f6zZumxp44TZikUCoVCoVAoTRZbkJ39+7GnjhNmKRQKhUKhUChtFleQ3RFmz5w5Q5ilUCgUCoVCoTRVQkF2c3PTnDlzhjBLoVAoFAqFQmmrhILs7JlZwiyFQqFQKBQKpakiCbKzf585c8YsvXTqNGGWQqFQKBQKhTJ6kQbZ2d8vnTpNmKVQKBQKhUKhjF+0QXZzcy7MAgAAALWlBuDtMEuhUCgUCoVCofRY/j8PDqepAFsQygAAAABJRU5ErkJggg==) any suggestion?
*) replace Xxxxxxxx with the correct name!
This AR488 works with multiple targets or only with one?
Which is the string shown in the debug log about the ++ver string?
I am using a Leonardo clone, and with the patched version apparently the ++ver does not return anything.
I have built a UNO based AR488 module and am using it to receive screen dumps from a TDS744A Tek 'scope using some software I have written.
The AR488 is in mode 0 and when the operator presses the scopes "HARDCOPY" key the file is recieved and written to a file.
At the moment the only way I have been able to detect the end of the datastream is to have a timeout on the read on the AR488 interface.
Is there a better way to detect the scope having sent the last character ?? An EOF indicator, perhaps, that I can poll ?? There doesnt seem to be anything in the stream for EOF (it's a binary stream anyway).
TIA
Dave
Is there any owner of a REAL Prologix interface who can do the following test:
- Open EZGPIB
- once the program has started, open the [Debug Message] window (Alt-D)
- publish the contents of this window
Thanks in advance....
Elio.
You mean this?
*IDN?
> ++read
TOELLNER,TOE8815-32,0,V1.34
gpibReadByte: timeout waiting for DAV to go LOW
Bytes read: 28
Timeout waiting for sender!
Is this DAV timeout "normal"? (I never used GPIB or ar488 before)Code: [Select]*IDN?
> ++read
TOELLNER,TOE8815-32,0,V1.34
gpibReadByte: timeout waiting for DAV to go LOW
Bytes read: 28
Timeout waiting for sender!
++eoi 1
++eor 2
It is working now.Greatly appreciated. Just built a 3rd adapter and still no luck. Anything obvious other than not soldered in pic?
Well finally got ticked off enough to open up the meter and behold what I find. Have to blame myself due to replacing batteries and all caps.
Second meter was plugged in right and after fixing connector in first one both still not working. TBC
I have some of them (white color), version 3 with the correct hole size:
I paid just 5.20€ for 30 pieces (JLCPCB): I can ship some of them but you have to contact me via a private message.
Attached you will find the gerber files (directly uploadable to JLCPCB): just 3.30€ for 5 pieces or 5.45€ for 30 pieces....
mcj7247: I could really use some direction, or perhaps even a Digikey part number, to the caps that require replacement?
QuoteNot Digikey but these are the ones I used. Apart from the value and the pin spacing, what's very important is that they are Class Y2. https://www.eevblog.com/forum/testgear/first-bench-multimeter-fluke-8840a-vs-hp-3478a/msg3100584/#msg3100584 (https://www.eevblog.com/forum/testgear/first-bench-multimeter-fluke-8840a-vs-hp-3478a/msg3100584/#msg3100584)
They popped up in Digikey part finder so thank you. I'll add them to my order.QuoteIf you'd like to read the proceedure I used for replacing the 3478a battery, read this thread; specifically the following two messages: https://www.eevblog.com/forum/testgear/first-bench-multimeter-fluke-8840a-vs-hp-3478a/msg3008694/#msg3008694 (https://www.eevblog.com/forum/testgear/first-bench-multimeter-fluke-8840a-vs-hp-3478a/msg3008694/#msg3008694) and https://www.eevblog.com/forum/testgear/first-bench-multimeter-fluke-8840a-vs-hp-3478a/msg3015428/#msg3015428 (https://www.eevblog.com/forum/testgear/first-bench-multimeter-fluke-8840a-vs-hp-3478a/msg3015428/#msg3015428)
Any calibration data read from the meter can be decoded using this script:
https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg3210132/#msg3210132 (https://www.eevblog.com/forum/repair/hp-3478a-how-to-readwrite-cal-sram/msg3210132/#msg3210132)
Print the output and tape it to the inside of the meter for the next guy (which may be you).
Let's hope not but I'd rather be prepared. And this will be a huge help. I'm confident with AR488/arduino side of the hardware connection but I'm going to need to study the command set in the manual to understand how to request the calibration data. I'm not Linux savvy either. I appreciate the info and thanks for sharing.
From the arduino monitor I could not send commands, (AR488 and Arduino UNO), not even sending ++ ver I had an answer with the version string, I installed YAT and with the exception of the first send, then everything works, 3478A and 34401A.
This is a very nice adapter. I created a Window App that quickly lets you test the adapter, to see if it works, just click on a com port from the list and issue commands. Nothing fancy. Works on my Windows 10 machine, uses .net framework 4.7.2. Let me know if it crashes.
Here is another software that works well with the first one I uploaded. Basically it issues a signal command and expects to receive data, if that data is a number then it's added to the graph using a double array. You can pan and zoom and zoom into a highlighted region. I tested it using a HP3478A, 3457A, and 6632A. Works with Windows 10. Let me know if it works, should you decide to try it.
Then the fun started: after a considerable time of |O I discovered that 2 of my Arduino's are 3.3V variants. Which I think is a non-starter for this project (or.. ?).I found 3.3V version works just fine, this is what I am using for my self-powered setup.
Then the fun started: after a considerable time of |O I discovered that 2 of my Arduino's are 3.3V variants. Which I think is a non-starter for this project (or.. ?).I found 3.3V version works just fine, this is what I am using for my self-powered setup.
If you get response to ++ver command then Arduino and communication works fine. You can check that GPIB lines are actually switching when a message is send. See if the instrument responds in any way (goes to remote, beeps an error). I usually use a Terminal program for debugging. You can also try a command that does not require a response, like a range change.
Also, how long is the cable that goes from Arduino to FTDI? I found sometimes it helps to drop the serial baud rate from 115200 to 57600.
in my (working) Arduino some of the pins numbers are different:
your mine
11----16
12----14
13----15
the rest are the same
I think you have to modify some pin definition in the sources....
(https://www.iot-experiments.com/content/images/2018/12/pro-micro-pinout.jpg)
#define DIO1 A0 /* GPIB 1 */
#define DIO2 A1 /* GPIB 2 */
#define DIO3 A2 /* GPIB 3 */
#define DIO4 A3 /* GPIB 4 */
#define DIO5 A4 /* GPIB 13 */
#define DIO6 A5 /* GPIB 14 */
#define DIO7 4 /* GPIB 15 */
#define DIO8 5 /* GPIB 16 */
#define IFC 8 /* GPIB 9 */
#define NDAC 9 /* GPIB 8 */
#define NRFD 10 /* GPIB 7 */
#define DAV 11 /* GPIB 6 */
#define EOI 12 /* GPIB 5 */
#define SRQ 2 /* GPIB 10 */
#define REN 3 /* GPIB 17 */
#define ATN 7 /* GPIB 11 */
to:#define DIO1 3 /* GPIB 1 : PORTD bit 0 data pins assigned for minimum shifting */
#define DIO2 13 /* GPIB 2 : PORTB bit 1 */
#define DIO3 12 /* GPIB 3 : PORTB bit 2 */
#define DIO4 11 /* GPIB 4 : PORTB bit 3 */
#define DIO5 8 /* GPIB 13 : PORTB bit 4 */
#define DIO6 9 /* GPIB 14 : PORTB bit 5 */
#define DIO7 10 /* GPIB 15 : PORTB bit 6 */
#define DIO8 6 /* GPIB 16 : PORTD bit 7 */
#define IFC 4 /* GPIB 9 : PORTD bit 4 */
#define NDAC A3 /* GPIB 8 : PORTF bit 4 fast control pins assigned to same port */
#define NRFD A2 /* GPIB 7 : PORTF bit 5 */
#define DAV A1 /* GPIB 6 : PORTF bit 6 */
#define EOI A0 /* GPIB 5 : PORTF bit 7 */
#define REN 5 /* GPIB 17 : PORTC bit 6 */
#define SRQ 7 /* GPIB 10 : PORTE bit 6 */
#define ATN 2 /* GPIB 11 : PORTD bit 1 */
5) recompileTry the following:
1) download the latest source code from https://github.com/Twilight-Logic/AR488
[snip]
just to simply things, attached you will find the file already modified for you.
However, while that means either will fit my PCB, there may still be some pin mapping differences.
And the mini pro has TTL serial instead of USB, so it needs an external FTDI adapter or similar.
The only pinout difference between the pro mini and the pro micro is that there's a reset pin on the mini pro thaht's ground on the micro pro.
However, while that means either will fit my PCB, there may still be some pin mapping differences.
And the mini pro has TTL serial instead of USB, so it needs an external FTDI adapter or similar.
my pro mini is accepted by EZGPIB withn an USB Prolific adapter cable tx/rx/gnd/vcc only.
@WKB
could you please provide your pin mapping so that the pro mini works with an PCB for pro micro in detail?
thank you Kutte
I want to build a relay scanner thats capable of accepting front panel buttons and commands via a GPIB-port to make the relays switch.
So far i only found open source USB-GPIB-Controllers, which arent capable of the Device Mode as far as i understand.
AR488 seems to be capable of said mode, but im unsure how to actually use this very big library to do what i want.
Can someone guide me a bit on how to do what i mentioned with the library?
Is AR488 capable of using GPIB-addresses in Device Mode, which would allow the usage of more than one DIY-scanner on the same GPIB-Bus when they all have different adresses?
Thanks.
Boat from China has arrived: fresh Arduino's :)
Silkscreen on these is of better quality, see attached picture. Testing to commence tonight (I hope).
Wilko
The only pinout difference between the pro mini and the pro micro is that there's a reset pin on the mini pro thaht's ground on the micro pro.
However, whiley that means either will fit my PCB, there may still be some pin mapping differences.
And the mini pro has TTL serial instead of USB, so it needs an external FTDI adapter or similar.
it surely is a "Pro Micro" and it must be recognized as a "Leonardo".
Please take care that, even if correctly programmed, it will not be recognized by EZGPIB. :(
these Leonardos (e.g. arduino pro micro) use a so called CDC USB-interface that does not provide a CTS signal.
So no joy, sorry for that Kutte
Unfortunately selecting a custom layout by #define AR488_CUSTOM results in a compile error for the serial port ::)
Like so:
215:46: error: cannot convert 'Serial_*' to 'HardwareSerial*' in initialization
HardwareSerial *arSerial = &(AR_SERIAL_PORT);
Right... when programmed with the 'stock' AR488 code and with AR488_CUSTOM left undefined it does work with the HP3478A.exe tool. It now happily reads data from the HP meter.
Sofar so good.
Wilko
It seems no one who reads this thread is also the owner of an original Prologix USB interface. In a previous post https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3212484/#msg3212484 (https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3212484/#msg3212484) I asked for the output results (debug) when EZGPIB starts, but with no avail.
Hm, but a patched EZGPIB (i.e. should no longer care about CTS) also does not work. 🤔
But I have two working AR488 with FTDI cables that work just fine so I am happy 👍🏻😁😁
Wilko
avrdude: erasing chip
avrdude: reading input file "C:\1\AR488.micro.32u4.hex"
avrdude: writing flash (32730 bytes):
Writing | ################################################## | 100% 2.92s
avrdude: 32730 bytes of flash written
avrdude: verifying flash memory against C:\1\AR488.micro.32u4.hex:
avrdude: load data flash data from input file C:\1\AR488.micro.32u4.hex:
avrdude: input file C:\1\AR488.micro.32u4.hex contains 32730 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.87s
[b]avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x70ff
0x9a != 0x98
avrdude: verification error; content mismatch[/b]avrdude: reading input file "AR488.ino.hex"
avrdude: writing flash (19714 bytes):
Writing | ################################################## | 100% 1.72s
avrdude: 19714 bytes of flash written
avrdude: verifying flash memory against AR488.ino.hex:
avrdude: load data flash data from input file AR488.ino.hex:
avrdude: input file AR488.ino.hex contains 19714 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.38s
avrdude: verifying ...
avrdude: 19714 bytes of flash verified
avrdude done. Thank you.> *IDN?
> ++read
HEWLETT-PACKARD,34401A,0,5-1-1
gpibReadByte: timeout waiting for DAV to go LOW
Bytes read: 32
Timeout waiting for sender!
> MEAS:VOLT:AC?
> ++read
+1.47722700E-03
gpibReadByte: timeout waiting for DAV to go LOW
Bytes read: 17
Timeout waiting for sender!
My initial thought was to increase the value of ++read_tmo_ms, although that does not seem to be the issue here as the read process appears to have been completed. The other possible explanation is that the interface has not received the expected termination characters and assumes there is more data to come but the instrument is not sending any, therefore the read process times out. Looking at the HP34401 manual, the termination character over IEEE488 is just <nl>. By default the interface looks for CR+LF. You could try setting ++eor 2 which will check for LF (<nl>) only.
> ++eor 2
Set EOR to: 2
> *IDN?
> ++read
HEWLETT-PACKARD,34401A,0,5-1-1
Bytes read: 31
>
With regards to the first board, GPIB signals are HIGH when un-asserted and LOW when asserted. In controller mode (++mode 1) REN is asserted and therefore LOW, but in device mode (++mode 0) it is set to INPUT_PULLUP and therefore HIGH, expecting the controller to pull it low. On the other hand, A0 and A2 are mapped to data lines DIO1 and DIO3. The line state would be LOW to indicate that a bit is set but HIGH when the bus is idle. Therefore A0 and A2 being HIGH when the interface is idle would be normal. I am not sure why the serial port did not work.
Thank you much Wavey, that's what I needed to know. :-DD
I have created a 3d printed enclosure for the adapter with a pro micro.
See https://www.thingiverse.com/thing:4774570 (https://www.thingiverse.com/thing:4774570) for details and all files.
I have created a 3d printed enclosure for the adapter with a pro micro.
See https://www.thingiverse.com/thing:4774570 (https://www.thingiverse.com/thing:4774570) for details and all files.
Nice ! I like the way is screws together.
Could you make a version with less height ? I have usually built them with no socket for the 32u4 board, so there's only 3mm between boards or 13mm from the 24 pin socket flange to the top of the USB socket housing.
I am having trouble with System.IO.Ports in Visual Studio. It seems to want the serial port operating at a standard baud rate. It seems to have difficulty with the virtual serial port on the Pro Micro.
I tried the AR488 software on a Arduino Uno and I can transmit and receive the ++ver command and the response. This works if I set the baud rate to 115200.
I am having trouble with System.IO.Ports in Visual Studio. It seems to want the serial port operating at a standard baud rate. It seems to have difficulty with the virtual serial port on the Pro Micro.
I tried the AR488 software on a Arduino Uno and I can transmit and receive the ++ver command and the response. This works if I set the baud rate to 115200.
An interesting observation but 115200 is a standard baud rate. If Visual Studio cannot handle that speed, you could always try 57600 or 38400. Also set #define AR_SERIAL_BAUD to the same in AR488_Config.h.
Here is a simple script for C#, I can connect to the pro micro version without any issues. Make sure that the request to send property is enabled.
Hi, I created the ultimate HP 3478A control and data logging software for the ar488 adapter. It has everything that you can ask for. Measurement Graph, math waveforms, statistics, histogram, etc. Works with Windows 10, 8, 7.
If you have a HP 3478A then please, try it and give me feedback. I will be creating similar software for 34401A, 3457A, 3456A.
Finally came around to testing the AR488-library on my Arduino Mega board connected to a stripped GPIB-cable.
It worked immediately in Controller Mode when communicating with my HP 34401A and also worked in Device Mode when my USB-GPIB-HS spoke to it via Python.
Im thrilled to see it working out of the box directly :-+
In Device Mode the AR488 isnt capable of responding to a *IDN?-command with an answer, i assume?
It would be nice to actually be able to use DipSwitches to set the address in Device Mode, so one wouldnt need to connect to the Arduino to change the address in software. Will that be integrated into the library in the future?
I assume the Arduino is busy with the AR488-library and so i should use another µC to actually do my rather slow and amateur-programmer stuff like switching relays with its associated delays or is the library not bothered by it due to using interrupts for the time critical response stuff?
How do the LLO/LOC-commands coming from a controller influence the Device Mode actually? I can see the usage, but would expect that the Arduino in Device Mode activate two outputs for LEDs like "Front Panel Disabled" and "Remote Control Active" when seeing those commands?
Sorry for the many questions, i just think that your library could enable many hobbyists to build instruments with GPIB-capability, apart from the usage as a very nice and low cost controller. :)
Is there a way to donate to you WaveyDipole? Couldnt find a way to do that on Github.
@WaveyDipole:
Your Twilight-Logic/AR488_Store repository is down or removed?
Should I continue to use your AR488 program to work on the Tektronix 4924 Emulator?
Thanks!
Tried posting this in the beginners sections but didn't get a response after a few days so i figured I'd repost here to see if anyone can help.
I have an HP1630D I'm trying to get an inverse assembler on. I've built the AR488 and can get the HP to respond to button press commands and rst, but i can't quite get an assembler to load. Honestly, I'm not even sure I'm sending it right. I've been trying to send the files via coolterm's send text/binary file function. The best I can get out of the 1630 is a CRC error. I have been able to successfully invoke the TC command but have not been able to reload the config that TC generates.
Thanks for any suggestions in advance
@WaveyDipole:
Your Twilight-Logic/AR488_Store repository is down or removed?
Should I continue to use your AR488 program to work on the Tektronix 4924 Emulator?
Thanks!
That is very strange. Just had a look and it is still there as a private repository and you are still configured as a collaborator. I tried to send you another invitation but the system will not let me because you are already a collaborator.
Maybe its a GitHub glitch?
It might help to send one line or a chunk of no more than, say, 64 - 128 bytes at a time and have a short delay of a few milliseconds in between which could be done using a script.
Alright, I finished making GUI software for 34401A, 3457A, 3456A, and 3478A. They will work with Windows 10, 7, 8. I personally tested them on Window 10 and 7.
You can download the software from their GitHub links. Let me know if you encounter any issues.
For the HP3457A, I updated the software. I added the ability to send custom commands.Thanks! I was able to use it now for my current project involving scanning several channels at high resolution and it works well.
I am working on HP3457A Cal dump utility for AR488, it will be a separate app. The app will only read the cal info, not write it. As I am scared to implement the cal write feature and test it.Did you get a chance to finish the cal dump utility for HP3457A?
I have a potentiostat/galvanostat from EG&G Princeton Applied Research model 263A v2.19, with ieee 488 socket (attached picture). i need to connect it to a modern pc, do you think this AR488 will be suitable for the scope? How can i check the compatibility a priori?
Thanks for the confirmation!I have a potentiostat/galvanostat from EG&G Princeton Applied Research model 263A v2.19, with ieee 488 socket (attached picture). i need to connect it to a modern pc, do you think this AR488 will be suitable for the scope? How can i check the compatibility a priori?
Having had a look at the manual online, despite the characters on the rear plate, Appendix B describes this as a standard IEE488 port so I see no reason why the AR488 should not enable communication with the instrument using a USB port on your PC.
https://lin-web.clarkson.edu/~skrishna/Model_263A_Command_Set_Handbook.pdf
I got the Tektronix Hardcopy capture working with the latest firmware, for pro micro adapter. I used ++eor 7, ++eoi 1, ++read_tmo_ms 8000, ++addr GPIB_Address, everything else is default. I tested it with TDS784D and TDS684B.
Many thanks to artag. I was little bit confused with the archive name 32u4, but I can confirm that this design is for Arduino Nano (tested with MEGA328P)Could you point to the "GPIB connector you used" ?
Could you point to the "GPIB connector you used" ?
/Bingo
Apologies, I will put up the 32u4 (arduiino pro micro) version but that is indeed an earlier Nano layout.
Is this the right version for the 32u4 ?
https://oshpark.com/shared_projects/yfUOmUzA
It looks like you have spent quite a bit of time designing that hat for the Mega 2560! I had a look at your the schematic and layout. I am assuming that we are looking at the top of the board and the IEEE488 socket is facing up. If so, then I couldn't spot any obvious problem. This also assumes that the orientation of the socket is correct (narrow side towards the outer edge of the board).Thanks for the comment. All your assumptions are what I have done.
Its been a little while since I worked out the SN7516x chip details so I would have to set this up on a breadboard again. As a matter of curiosity, did you prototype this on a breadboard first?
Did you use sockets for the SN75161x chips? If so, then it should be straightforward enough to jumper them temporarily, trying one IC at a time. I also presume you have jumpered either JP1 or JP2? You should have only one or the other connected. Since you are using pin 5 for DC in the config, then connect only this pin. Otherwise if you want to use REN, then comment out the DC pin in the config.
I got components from Farnell today and will make a new one tonight.
...
I would like to setup a standalone data logger independent of my win7-64 pc that I use daily. I have a Win10 tablet that I thought would be ideal for the independent data logger using program 2) above however it has Win10-32 bit OS and this appears to be a problem for program 2), not verified I’m still checking. Program 1) above does not support the 82357B adapter, so that’s why I’m here exploring this option.
So finally the questions:
A) what arduino board should I use?
B) Has someone developed a readily available board that has whatever GPIB interface stuff on it?
C) Is such a board available either finished as a kit or in Altium or similar format so I can order one?
D) Has anyone reliably logged data from multiple meters using the Arduino solution and what logging software did you use?
Much appreciated,
J
FYI: I don't have personal experience with the Bluetooth setup but can confirm that the SN7516x driver configuration works.
https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3813158/#msg3813158 (https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/msg3813158/#msg3813158)
I got components from Farnell today and will make a new one tonight.
It is the update of my board design. I built a new board.
The board did not work either with or without the GPIB transceivers. Probably the GPIB interface of my instrument (Agilent 34001a) is not working properly. Maybe I can only use RS-232 or use the others' breakout design.
I only have this equipment with a GPIB interface. I Hope WaveyDipole can get it to work with his instrument.
I can confirm that Bluetooth works fine. See the attachments. It is directly powered from a 5V power supply instead of a PC.
Just need to verify which port is for AR488 itself. And unplug the Bluetooth module before you program Arduino.
I build AR488 with Mega 2560 and the GPIB transceiver chips (SN75160BN and SN75161BN). They are in the format of Arduino Shield. The design, manufacturing and source code files are in https://github.com/ONLYA/AR488-Bluetooth-Mega-2560 (https://github.com/ONLYA/AR488-Bluetooth-Mega-2560) if anyone wants to modify and manufacture it.
I built it yesterday but it did not work. The handshake signals do not even change. After tests, I believed that the transceiver ICs that I purchased on eBay cannot transceive the data. Probably I need to buy new ones on Mouser or Digikey.
Now I am considering shorting the pins to make the direct connections.
Is there anything wrong with my design and my source code that makes this not work?
Sorry to hear this. I so happens that I have a HP34401A here and I know that is works directly with the AR488, however I also set it up with the SN75161x configuration to test.It could be so many factors here: faulty cable, faulty GPIB ports, etc. The assertion tests of the data and control signals work fine before the SN7516X transceivers. I will check those factors one by one today later on.
Nice to know that Blutooth worked. Port Rx0/Tx0 is connected to the UART serial over for USB. However on the Mega2560 there is an alternate choice of ports. In the configuration you are using ([D]efault for Mega 2560) I seem to recall using Rx2/Tx2 pins for GPIB signals, but Rx1/Tx1 and Rx3/Tx3 could be used for Blutooth. That way there would be no interferance with the UART and programming. You could not see any output from the AR488 via the UART though, only Bluetooth.The UART port are shared in the source code and seems not configurable with the config file. I can change this part to make the UART ports configured and work separately. You can solder the "3" sides of JP3 and JP4 to connect the Bluetooth UART port to Rx/Tx3.
Hi, does this Mega-2560 hat now work ?
Richard
Thanks to WaveyDipole, the problem of the Mega hat is finally found. It is the wrong connection due to my misunderstanding of the GPIB connector orientation and the wrong library directly downloaded from the internet. What a serious mistake I have made! :palm:
I will correct and verify the design and update the status here as soon as possible.
The next thing I probably need to do is to desolder the expensive GPIB connectors...
Removing the connector with a soldering iron and solder sucker is likely to be tricky. Sometimes adding a little solder to the joint first to enable better heat coupling helps, but the joints attached to the ground plane can be awkward as the ground plane sucks all the heat away very quickly.It is really tricky to desolder a GPIB connector with those two basic tools. The original way did not suck all the solder and the remains became a thin layer in the hole, which is harder to get rid of. A better way (soldering iron and solder sucker on different sides) seems not able to be applied to this connector as I smelled plastic when I did this.
++auto 0
++addr 15
AP //sensor A
CW //cw-mode, fastest
AE FM 0 EN //averaging off
SWIFT FREERUN //freerunning swift mode
++read
++read
++read
...If I send a "++addr" command to the adapter and wait for the answer, can I be sure that the previous set frequency command has been completely dispatched to the instrument once I get the address answer or can the AR488 adapter reply while still processing the previous command?
What happens when I send commands to the adapter in too rapid succession, which may happen for commands that do not invoke an answer?
A call to read or write to a device must complete its read/write cycle before returning back to the main loop when the next command in the sequence can be processed.
++addr 19<CR><LF> //setting GPIB address 19
++eor 2<CR><LF> //HP8350 answers with LF only, the Prologix doesn't need this
++auto 1<CR><LF>
IP<CR><LF> //Instrument preset
OI<CR><LF> //read identifier string
I am having trouble controlling an HP8350B with the AR488 USB adapter, while the same code runs fine with an original Prologix adapter.
I am having trouble controlling an HP8350B with the AR488 USB adapter, while the same code runs fine with an original Prologix adapter.
Question about the AR488-ESP8266-addon firmware:
I run my ESP8266 interfaces all in client mode connected to a local access point.
Now, if I happen to switch on the AR488-ESP8266 devices BEFORE I switch on the access point (it is dedicated to the lab and only running when I'm there), the access point won't be found and the ESP8266 comes up in AP mode. As far as I understand, the access data to the access point is lost then, correct? If I power the device down and back up when the local access point is running, it will no longer connect, but will come up in AP mode again. Thus, in such a case I'll have to manually re-connect all devices to the local access point, which is a lot of work.
Is there any way to avoid this? I do not need the device to come up in AP mode if the access point is off. But it should connect to the access point next time it is powered up again.
Thanks, Tom
Hi I've just built myself an AR488 with arduino micro. I can send commands like ++ver and receive a response back.
But I'm having some difficulty connecting to my Fluke8840a, command ++addr responds with 1 so i've set the hardware address to 1.
I'm hoping username kc9qvl is still on this forum as I see in post #412 he got it working.
I was hoping he could share the secret to get the Fluke chatting.
A random question, is the AR488 compatible with PyVISA?
using an ESP32 instead of an (AVR) Arduino may help here. Since the wifi management is part of the firmware, it's a bit easier to deal with this kind of situation.
Over time there have been some questions about serial buffer overruns serial handshaking on Arduino boards. Some boards support handshaking, others do not. I have recently done some testing of RTS/CTS and XON/XOFF handshaking on the most commonly available UART chips. I thought this information might be of interest to some. Attached is a summary the results of these tests.
Using the test program, it was possible to send a test data file from one serial port to another without data loss, even when the receiving port was running much slower than the sending one. However, this only worked with certain UART chips but not others. The attached shows which UART chips will or will not support serial handshaking, the steps required and the problems encountered.
I do plan to implement the technique used in the AR488 code at some point in the near future and document the findings in the AR488 manual.
sub initialised
{
my ($self) = @_;
return unless $self->version() =~ /^Prologix/;
# Set the Prologix into a state we like
$self->auto(0);
return unless $self->auto() == 0;
return 1; # OK
} sub initialised
{
my ($self) = @_;
#
# needed prior to $self->version() # on AR488
$self->read();
#
return unless $self->version() =~ /AR488/;
print("initialised:OK\n");
return 1; # OK
}
#!/usr/bin/perl
#
# Send some commands to the HP 5316A
#
use lib '.';
use strict;
use AR488;
$Device::GPIB::Prologix::debug = 1;
my $dev = AR488->new('/dev/ttyACM0:115200:8:none:1:none');
if (!$dev) {
print ("problem with device\n");
exit
}
$dev->addr(4);
$dev->auto(1);
$dev->send("IN");
$dev->send("TR0");
$dev->send("FN1");
#
# Initialize to the following
# FN1 Frequency A
# AS0 A triggers on positive slope
# BS0 B triggers on positive slope
# TR0 A and B trigger based on front panel control
# WA0 Continuous gating. output if addressed
# SR0 Polls srq at end of measurement
# GA0 Gate range is long entered on front panel
my $res = $dev->read();
$dev->close();
print("Reading: $res\n");hi everyone. i've got a problem...
i can connect to my ar488 (pro micro) with putty on windows and some of the commands were received by the instrument (with ++llo goes in rem mode), but I'm not able to set up the connection in ke5fx... could anyone help me?
the instrument is a par 263a potentiostat.
Would it be possible to set up two AR488 adapters to communicate with each one another ( for the sake of testing ) ?Every device including the controller needs a unique address. Controller is typically 0.
I have tried to set up one as controller ( mode 1 ) and the other as device (mode 0) but running a ++spoll from the controller does not seem to find the device. Both are set to address 5.
Every device including the controller needs a unique address. Controller is typically 0.
/*** MEGA 32U4 based boards (Micro, Leonardo) ***/
#elif __AVR_ATmega32U4__
/*** Board/layout selection ***/
#define AR488_MEGA32U4_MICRO // Artag's design for Micro board
//#define AR488_MEGA32U4_LR3 // Leonardo R3 (same pin layout as Uno)
x_diag function. Try setting and double checking each pin at the output to make 100% sure of the connections. I've got this code working with the arduino pro micro, which has a built-in USB port. It's also a very small board that fits neatly on the back of a GPIB connector, making a really tiny interface.
I've designed (but not yet received) a PCB to mangle the wiring appropriately but will publish that once it's proven.
Waveydipole has a copy of my changes (which also support the Uno and Mega versions in the same Arduino project) and will make that available in due course.
Apart from the size (an arduino nano also fits quite nicely on the back of a plug), the use of the 32u4 should make it possible to support the RTS/CTS pins correctly (though I haven't tried to do that yet) and maybe at some point support USBTMC as an alternative to serial.
++ver
AR488 GPIB controller, ver. 0.51.09, 20/06/2022
++xdiag 0 0
++xdiag 0 255
++xdiag 1 0
++xdiag 0 0Query INTERRUPTED
A command was received which sends data to the output buffer, but the output buffer contained data
from a previous command (the previous data is not overwritten). The output buffer is cleared when
power has been turned off, or after a *RST (reset) command has been executed.
"invalid character received: *IDN/<LF>"
I double, triple checked - and my termite terminal says I sent *IDN? - is the ? being removed somewhere?
Is there a source for decoding the data on the GPIB? I tried looking through the standard, but couldn't find anything - is it simple ascii? I tried running the numbers through a binary to text converter but only got rubbish. I tried decoding using 1 for HIGH as well as 0 for HIGH, Ch0 connected to DIO1 -> Ch7 to DIO8. I've attached the measurement files as csv - though there isn't too much to them. Images are below.
I'm using a saleae logic 8 in their logic 2 software (confusing naming scheme).
Hope you have some luck with your device - were you using the ++auto 2 command?
Thanks again JustJason - i admit the 10s caught me out - the AR488 manual doesn't mention it returns automatically haha.
I think I have figured it out...
Under the default configuration, the controller is not automatically configured to attempt to read a response from an instrument after a sequence that is not a controller command (beginning with ++). *IDN? is one such command. As such, the ++auto 2 should be sent to the controller.
Hi, with the last firmware version, Timelab (for my experience) doesn't work anymore with my Hp5334a. In particular, I cannot set the instrument in talk mode.
Has anyone had the same problem?
thanks in advance
I'm using a saleae logic 8 in their logic 2 software (confusing naming scheme).
The sigrok decoder will work with the cheap Cypress breakouts. Just like the AR488 they can be handwired, but there's a pcb here
https://oshpark.com/shared_projects/1FVMoqoQ
The only components are connectors and the Cypress board.
I'll put a photo up.
I have six instruments on the bus. I think it would be more convenient to talk to the instruments through a single interface.
Does this make sense?
Regards,
Jay_Diddy_B
Hi,
I think I have detected an incompatibility between the AR488 and the Prologix adapter that seems to cause an issue with the KE5FX VNA toolbox.
The issue is with the ++spoll command. The KE5FX software issues it with an address, i.e. ++spoll 16, where 16 is the primary GPIB address of the polled instrument.
Here is the command sequence that works successful with the Prologix adapter in combination with the HP8510B VNA:
++addr
16
++spoll
1
++spoll 16
1
For better visibility I have indented the adapter responses. So far so good.
Now, here is the same sequence using the AR488:
++ver real
AR488 GPIB controller, ver. 0.51.09, 20/06/2022
++addr
16
++spoll
1
++spoll 16
=> no response from the AR488 which causes the KE5FX VNA tool to lock up.
Have I misunderstood something or can there be done something about this problem?
Thanks and best regards,
Tom DG8SAQ
Hi, with the last firmware version, Timelab (for my experience) doesn't work anymore with my Hp5334a. In particular, I cannot set the instrument in talk mode.
Has anyone had the same problem?
thanks in advance
Tom, could you log an issue please. It will help me keep track.
The problem that I am trying to solve
The first write to a power supply, HP 6673A, doesn't work 100% of the time. This happens if the AR488 is disconnected from the USB port and then written to. I have seen that there is no activity on the GPIB bus. My next step will be to look at the connection between the CH340 and the ATMEGA328P. I don't know if the issue is in my VB.net program, the com port drivers or the AR488.
I have found that if you open a port the DTR line will reset the Arduino.
I am using an Arduino nano, I am not sure which bootloader.
Regards
Jay_Diddy_B
Snip ...
There is approximately a one second delay while the bootloader does its stuff. Any data sent over serial while the bootloader is running and before Serial is initialized (i.e. Serial.begin() ) is simply lost. For this reason, if using one of those boards, time has to be allowed after the serial connection is made, for the Arduino to initialise.
Snip ...
The camera angle probably makes it look a lot worse than it is, but I do hope that there is not too much mechanical stress on that PCB joint. The HP Termination Adapter looks quite bulky!
/***** Enable SN7516x chips *****/
/*
* Uncomment to enable the use of SN7516x GPIB tranceiver ICs.
* This will require the use of an additional GPIO pin to control
* the read and write modes of the ICs.
// Mod JDB
*/
#define SN7516X
#ifdef SN7516X
#define SN7516X_TE 6
#define SN7516X_DC 13
// #define SN7516X_SC 12
#endif
for the life of me with the latest arduino ide 2.0.1
It always miss some files devnull.h or pro_micro.h BUT they are there ??? or in the same folder than the ar488 ino file
even reverted to the old 1.8.x no luck
all come from : https://github.com/Twilight-Logic/AR488 (https://github.com/Twilight-Logic/AR488) and i use the latest SRC folder ???
and the arduino is the sparkfun pro micro at 16mhz : https://www.sparkfun.com/products/12640 (https://www.sparkfun.com/products/12640)
i recall there was some problems with the eeprom on theses thing, i have one somewhere who is configured as an logic analyser .... saleae clone
what is the code put in it ? just to help the others
for the life of me with the latest arduino ide 2.0.1
It always miss some files devnull.h or pro_micro.h BUT they are there ??? or in the same folder than the ar488 ino file
even reverted to the old 1.8.x no luck
all come from : https://github.com/Twilight-Logic/AR488 (https://github.com/Twilight-Logic/AR488) and i use the latest SRC folder ???
and the arduino is the sparkfun pro micro at 16mhz : https://www.sparkfun.com/products/12640 (https://www.sparkfun.com/products/12640)
If you are using a case sensitive OS (filesystem) ... Ie. linux.
I have been "bitten" several times by the #include statement not matching the case of the file on the disk.
Usually won't be an issue on a M$ OS , but will be on linux & prob MAC too.
Not saying that this is the issue but ..... Worth a check.
Tried a new board NANO V3 BUT it as an Mega328 BP and once again it doesn't work with all the web tricks, another shi#$#$% clone, you have the old bootloader and the new bootloader ....
with the sketch blink ................ no led blink nada niet nothing |O
tried other boards support for the nano v3 with the BP variant web tricks no avail
ARDUINO GPIB firmware by E. Girlando Version 6.1
++id verstr AR488 GPIB-USB version 6
++savecfg
++id verstr
#define FWVER "AR488 GPIB controller, ver. 0.51.15, 12/10/2022"#define FWVER "AR488 GPIB-USB version 6"So I built the AR488 for the first time.
I uploaded the code 0.51.09 ( with no changes ) Arduino Mega with D wiring config. ( is there any changes required?)
I can get a response to ++ver, but get no reply to ++idn 1 or *idn?
Testing with 34401A ( set to gpib addr 22).
Any suggestions to troubleshoot? How could I enable Debug?
Thanks.
//#define DEBUG_ENABLE//#define DEBUG_GPIBbus_SEND++idn 1
++idn
++auto 2
++auto
So I built the AR488 for the first time.
Testing with 34401A ( set to gpib addr 22).
Any suggestions to troubleshoot? How could I enable Debug?
Thanks.
Hi there, does anyone have in DE, or around, some of the Jay's PCBs for the buffered version of the adapter, or is anyone interested in a group order in Germany ?
If someone has available boars and can send please PM me, for group buy let's do it here if it's not too much of a hassle.
Cheers,
DC1MC
Many thanks Jay for all the support, unfortunately I have exactly zero experience with ordering PCBs to be manufactured, could you kindly go "the last mile" and share the link to the PCB service so I can order a number of them, with the Christmas stuff and the general tardiness of the German customs, they'll arrive most likely after my Christmas vacation will be over, but that's on me for MY tardiness and at least some boards will be quickly available for members in DE.
Cheers,
DC1MC
Dear dc1mc,
Thank you for your order from JLCPCB. It’s our pleasure serving you. We are pleased to inform you that the items listed below have been packaged and are waiting for pick up by Global Standard Direct Line.
Hi @DC1MC , Just straight from the Arduino, is this something the buffer might fix?
Ok, I was a bit in doubt because, probing around the data lines it seemed that when the signal was coming through the edge was not visibly degraded.
I will make myself one of Jay Diddy Boards, and see. at worse, I will use one Arduino per device.
Thanks!
With regards to the failed programming, I found I had to do this (copied from my notes):He is talking about the ATmega328 Nano, not the ATmega32U4 Micro.
Select "Arduino/Genuino Micro" as the board and short the RST/GND pins briefly during upload.
Incidentally I was considering to move the AR488 code to VsCode/PlatformIO at some point but haven't made a decision on that yet. However, before I get ahead of myself, I will test on Arduino IDE 2.0.x first.
Incidentally I was considering to move the AR488 code to VsCode/PlatformIO at some point but haven't made a decision on that yet. However, before I get ahead of myself, I will test on Arduino IDE 2.0.x first.
Please, no.
Platfomio is an insanely overcomplicated kitchen sink thing that some may find useful for their projects. In my view it's not something that should be imposed on an open source project. VSCode even more so - an overcrowded interface where nothing is obvious and there is far too much baggage to trap the unwary.
AR488 is a great little project. Simple to build electronically and in software. It suits the Arduino IDE very well - The IDE needs very little learning because it doesn't have much functionality. For a tool that you might be using just to put together your nice cheap little HPIB adapter it's great. Not as simple as just typing 'make' but at least it's cross-platform and self-contained.
I''m not an arduino-only person. I've been developing on embedded projects since 1980. But I think it suits a niche very well, and the unholy duo of platformio and vscode make me want to cry. Platformio has the saving grace that it can generally be run from the command line but please don't use VScode as the environment, at least not as the default for the casual builder.
FWIW, my adapter (not exactly the same design here) drives two loads just fine, unbuffered. With an XMEGA MCU at least. So cables or power sound more likely.
Tim
Snip ...
Also a note to Jay: what is the purpose of J1 ?
Cheers,
DC1MC
So I have still materials for two buffered boards and also for four unbuffered, does anyone knows if there is a manufacturing package (zip) with the unbuffered PCBs, I've seen the rendering but I wasn't able to find the archive in the thread |O.
Snip ...
Cheers,
DC1MC
Thanks Jay for chiming in :-+, besides the little modification (just x-uple check: the SC signal remains commented ?) everything is as it comes from the repository ?
All this interrupt stuff works now or should remain commented ?
I'll torture it tomorrow and then look closer to the code :). so far the sketch loads on the assemble board and nothing gets hot, so I have great expectations :)
Cheers,
DC1MC
A small note to WeavyD, maybe it could be a good idea to edit the first post and add the PCB archives for both of the versions as well as the schematics, it could make the life of future AR488 builders a bit easier.
Please, no.
Platfomio is an insanely overcomplicated kitchen sink thing that some may find useful for their projects. In my view it's not something that should be imposed on an open source project. VSCode even more so - an overcrowded interface where nothing is obvious and there is far too much baggage to trap the unwary.
AR488 is a great little project. Simple to build electronically and in software. It suits the Arduino IDE very well - The IDE needs very little learning because it doesn't have much functionality. For a tool that you might be using just to put together your nice cheap little HPIB adapter it's great. Not as simple as just typing 'make' but at least it's cross-platform and self-contained.
I''m not an arduino-only person. I've been developing on embedded projects since 1980. But I think it suits a niche very well, and the unholy duo of platformio and vscode make me want to cry. Platformio has the saving grace that it can generally be run from the command line but please don't use VScode as the environment, at least not as the default for the casual builder.
ARduino mostly 'just works', that missing library excepted (waveydipole : just include the code if its small. avoids the need to track versions and does whats required)
I made some test and AR488 actually works with Pymeasure, and pyvisa as they support the prologix adapters, it's great. I still have my errors with the Philips synthesiser under those, will see if the buffers make any difference.
Just after a quick check of the manual it seems the commands for the PM2534 are in capital letters and I think also with underscores instead of spaces:
TRG_I
OUT_S
maybe that's the issue?
Ok, but it should still be capitalised.
Hello everyone.
I hope i follow the rules and dont post this message to the wrong place.
Big respect for all your work arround this ar488 project.
Guys I need help. I want to read data from 2 different yokogawa WT 130.( Fat multimeters) The goal is to record the data in a Excel file. I know excel is not the best to datalog but its part of a greater project and I need it to be like that.
So far i have done my interface using an arduino nano and sacrificing an old national instrument gpib cable. I also 3d printed a litle case for it ( not perfect but i can share the file if you want)
That was the easy part, now I am trying to understand what do i need to install on my computer to communicate with the device.
I'm studying électrical engineering so all this is a bit out of my usual skills. Do i need drivers? Maybe NI488.2 drivers? Do i need a software in particular like "FTDI RS232/USB terminal emulator (i dont even know what it is) or maybe visa?
In witch direction should i work?
Thank you.
//#define AR488_CUSTOMOk thks a lot Nx-1997, not hijacking this thread
Works fine, use R&S configurator and use R&S Visa as preferred
For the "old" Agilent / Keysight DMM, i had to install old I/O librairies to make it work ??
Keysight DMM works !!!
Ill continue to read this thread, i have ordered ARTAG pcb's for the sparkfun pro micro and see .... Gpib plugs received
/*** MEGA 32U4 based boards (Micro, Leonardo) ***/
#elif __AVR_ATmega32U4__
/*** Board/layout selection ***/
#define AR488_MEGA32U4_MICRO // Artag's design for Micro board
//#define AR488_MEGA32U4_LR3 // Leonardo R3 (same pin layout as Uno)
There is nothing wrong with xyphro's UsbGpib (https://github.com/xyphro/UsbGpib (https://github.com/xyphro/UsbGpib)) adapter. All you need with this adapter is to install R&S Visa Software (https://www.rohde-schwarz.com/ca/applications/r-s-visa-application-note_56280-148812.html (https://www.rohde-schwarz.com/ca/applications/r-s-visa-application-note_56280-148812.html)), nothing else. Also, the solution to the meter's initial error is shown on his GitHub page.
This adapter is a lot faster then the AR488 adapter, in terms of data transfer speed. Much better then even the commercial adapters.
So it begins, I have found my old project bag with connectors and buffers from saner and healthier times, not let's assemble the first board from Jay, a beautiful menstrual red, mine are puke green :-DD.
Still boards available for DE !!!
Cheers,
DC1MC
if I somehow manage to get over my crazy sickness.
Is it possible to bodge in a multiplexer or temp humidity sensor or are all needed pins taken/unable to be interrupted?
Yes the two bluepill modules i got did not work either, so i ordered two STM32L433CCT6 to replace the bad MCU. This worked well and i could use a cheap STLink programmer and CubeMX. USB worked out of the box and without pulling in a realtime OS. For the GPIB test i had to mod the bluepill once more:
- "free" PB2 (L433 doesn't need Boot1)
- wire 1K5 USB pullup to PA8 in order to automate USB re-enumeration at boot time (USB "pretreatment")
There are 16x 2k7 pull-ups to 3.3V on the bottom.
Regards, Dieter
Quite some time ago, someone produced a layout that freed up the SDA/SCL pins which allowed a sensor to be attached.
186 thru 197 deal with interrupts. Since I’m using a NANO, should the interrupt section be uncommened?
205-216 deal with dip switches, which I don’t have. Should line 205 (#define DIP_SWITCH) be commented out?
$17 in shipping for 1 pcs :scared:
The Chinese manufacturer Fuyconn (http://www.fuyconn.com/) is now selling its connectors on AliExpress (https://www.aliexpress.com/item/1005005334693654.html?spm=a2g0o.productlist.main.7.142c19ecEKBd6l&algo_pvid=63a8e9ad-0f9a-468b-87ca-f35056500503&algo_exp_id=63a8e9ad-0f9a-468b-87ca-f35056500503-3&pdp_ext_f=%7B%22sku_id%22%3A%2212000032650758236%22%7D&pdp_npi=3%40dis%21EUR%212.96%212.96%21%21%21%21%21%4021227e5116795810787216854d070b%2112000032650758236%21sea%21NL%21793968063&curPageLogUid=K7qevFC9WwKb).
The Chinese manufacturer Fuyconn (http://www.fuyconn.com/) is now selling its connectors on AliExpress (https://www.aliexpress.com/item/1005005334693654.html?spm=a2g0o.productlist.main.7.142c19ecEKBd6l&algo_pvid=63a8e9ad-0f9a-468b-87ca-f35056500503&algo_exp_id=63a8e9ad-0f9a-468b-87ca-f35056500503-3&pdp_ext_f=%7B%22sku_id%22%3A%2212000032650758236%22%7D&pdp_npi=3%40dis%21EUR%212.96%212.96%21%21%21%21%21%4021227e5116795810787216854d070b%2112000032650758236%21sea%21NL%21793968063&curPageLogUid=K7qevFC9WwKb).
$17 in shipping for 1 pcs :scared:
Have just posted a further update (0.51.15) this morning that fixes a couple more bugs.
Still working on the MCP23x17 stuff.
Have just posted a further update (0.51.15) this morning that fixes a couple more bugs.
Still working on the MCP23x17 stuff.
I recall reading that recent MCP23017's aren't completely bi-directional. GPA7 and GPB7 can only go one direction (output only). MCP23S17 (the SPI version) doesn't have that problem. See: https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP23017-Data-Sheet-DS20001952.pdf
Got a notice from Digi-Key yesterday that the DIP version of the SN75160 is going EOL. The SMD version looks like it will still be available for now. If anybody wants factory-fresh DIP versions of the SN75160 on hand for prototyping, you may want to think about getting them soon.
https://www.digikey.com/en/products/detail/texas-instruments/SN75160BN/370217 (https://www.digikey.com/en/products/detail/texas-instruments/SN75160BN/370217)
If you want to do electronics these days, you have no choice but to adapt, and it makes no sense hanging onto the dinosaurs.
If you want to do electronics these days, you have no choice but to adapt, and it makes no sense hanging onto the dinosaurs.
Isn't the main purpose of building these GPIB interfaces so that we can continue to hang onto our T&M dinosaurs and boat anchors? :P
If you want to do electronics these days, you have no choice but to adapt, and it makes no sense hanging onto the dinosaurs.
Isn't the main purpose of building these GPIB interfaces so that we can continue to hang onto our T&M dinosaurs and boat anchors? :P
You don’t do nothing to those boat anchors, you use them as is to make something new or to learn. If you want to make something new, you’ll have to adapt. Not only that the old parts are disappearing but the new ones offer much more flexibility and performance. This adapter that we’re talking about is only used to connect to the boat anchors.
If you want to do electronics these days, you have no choice but to adapt, and it makes no sense hanging onto the dinosaurs.
Isn't the main purpose of building these GPIB interfaces so that we can continue to hang onto our T&M dinosaurs and boat anchors? :P
You don’t do nothing to those boat anchors, you use them as is to make something new or to learn. If you want to make something new, you’ll have to adapt. Not only that the old parts are disappearing but the new ones offer much more flexibility and performance. This adapter that we’re talking about is only used to connect to the boat anchors.
@ Miti that's your opinion, not the same for others ... some "old" stuff where better in many ways ... ''new'' doesn't mean better since quality and durability in some case(s) are long gone
For me the reason to make GPIB adapters was security. When i looked into the process table in my workstation and saw several processes installed by NI and whoever even when i wasn't using any of their stuff i wanted to become independent of that. No sniffing in our lab.
14 years ago i made some GPIB controllers based on XILINX CPLD with a FT245. They implemented only the basic bus handshaking, which means they require quite some library on the host to execute the usual GPIB transactions. Connecting two of them back-to-back one can transfer at 2 MBytes/sec.
Recently i made some STM32 based adapters with text interface to be used with a terminal program, much like the AR488. I am using it all the time. It can also support I2C ambient sensors, precision temperature monitoring with a ADS1256, SPI control of a relay scanner and a transparent RS232 connection. I want to use that for a setup with a Keithley 2182A nanovoltmeter.
Regards, Dieter
So is 5V recommended where possible?
/*** UNO and NANO boards ***/
#elif __AVR_ATmega328P__
/* Board/layout selection */
#define AR488_UNO
#define AR488_NANO
//#define AR488_MCP23S17
//#define AR488_MCP23017
I found the problem. In the source, as coming from github, there are two Arduinos defined for the 328P architecture:
Any idea what im doing wrong? Apparently the 3458A never sets the weighted sum of the STB to >=128, while this method worked a few years ago with a GPIB-USB-HS-adapter.
Date,COM #,Status,Message
9:33:02 pm,COM7,Send,++ver
9:33:02 pm,COM7,Recieved,"AR488 GPIB controller, ver. 0.51.18, 26/02/2023"
9:33:11 pm,COM7,Send,*idn?
9:33:12 pm,COM7,Send,++read
9:33:12 pm,COM7,Recieved,"HEWLETT-PACKARD,34401A,0,9-5-2";; AR488 B:1 Device HEWLETT-PACKARD,34401A, do not match: null;; Found Agilent 34401A on AR488 A:1I tried using TestController over a Nano based AR488 with an HP 34410A DMM connected to a laptop and it doesn't work.
Using the AR488 Utility it is possible to talk with the nano and to identify the DMM
......
However using TestController (latest verion) it cannot identify the DMM
I have seen this problem mostly with Chinese Nano clones. They are still rebooting during the TC initTried those delay settings to no avail unfortunately.
there is some who have different boot-loaders for 32u4Yes, Coromonadalix, and for the nano too. Your message gave me the indirect hint to try selecting an Arduino Uno as target in the IDE as that is near the same as the Nano except for the physical size. And that made it work!
Can anyone help me by uploading for me the HEX file for Nano on atmega328 here or other sites? I don't have a computer, just a smartphone, so I can't use the Arduino IDE standard
Just wanted to note that I just made a pull-request to the ESP32 repo to introduce ESP32S2 support.
General support has already been there - what's new is the support of the USB-peripheral in the ESP32-S2 module.
This allows to build simple and small adapters.
I attached photos of my first rev... it features ESD protection and programs via the internal USB and uses the same for comms.
Of course, rev1 has some medium d'oh... so there will rev2 in the close future.
Maybe this one will get open-hardware (I need to check all the 3d models, footprints,... to see if there's some licensing/copy-right issues).
If there's some additional demand (I guess, I'll need 10 for my museum...ähhh... lab to get rid of all these GPIB cabling), I could make my batch bigger.
Regards
Bright thoughts to everyone! I tried to compile the project in ArduinoDroid application for sndroid smartphones and I'm getting a lot of compilation errors. the project is not going to happen.
https://github.com/Twilight-Logic/AR488/issues/42
I also tried to compile the project in the Arduino IDE online editor - the project is assembled but does not generate hex code.
Can anyone help me by uploading for me the HEX file for Nano on atmega328 here or other sites? I don't have a computer, just a smartphone, so I can't use the Arduino IDE standard
I think I have found the problem:
My latest batch of HC06 modules appears to be built with faked chips.
These only work without data loss up to 57,6 kBaud!
An earlier batch of the same modules from a different supplier shows no problems at all at
115,2kBaud.
SO BEWARE OF FAKE MODULES!
Tom
If you have a sample from both batches maybe you can publish a side by side picture to help future users chose them properly. Of course, if they're identically looking then is a tough choice.
AR488 0.49.14 read calibration data cheksum good:
Reading calibration data.
**********
Verify checksums.
@@@CA@BLLLNLG : CkSum = (199 + 56) Checksum OK.
@@@@CABLLCOLO : CkSum = (207 + 48) Checksum OK.
@@@@@DBLLOELM : CkSum = (205 + 50) Checksum OK.
IIIIIDAEBAOKF : CkSum = (182 + 73) Checksum OK.
@@@@@@AEBMNML : CkSum = (220 + 35) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BADODEL@ : CkSum = (192 + 63) Checksum OK.
IIII@D@E@MNKG : CkSum = (183 + 72) Checksum OK.
IIIIIA@EDNNJL : CkSum = (172 + 83) Checksum OK.
IIIIII@ECDDKI : CkSum = (185 + 70) Checksum OK.
IIIIII@EABLKE : CkSum = (181 + 74) Checksum OK.
IIIIII@EBBOKA : CkSum = (177 + 78) Checksum OK.
IIIIII@EBMAKD : CkSum = (180 + 75) Checksum OK.
IIIIII@EBDOJO : CkSum = (175 + 80) Checksum OK.
@@@BF@CNOE@MB : CkSum = (210 + 45) Checksum OK.
@@@@BECN@@MMJ : CkSum = (218 + 37) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BCLCOBKJ : CkSum = (186 + 69) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
Reading calibration data complete.
Calibration data checksum valid.
------------------------------------------------
AR488 0.51.18 read calibration data checksum failed:
Reading calibration data.
**********
Verify checksums.
@@@CA@BLLGNLG : CkSum = (199 + 51) Checksum Fail.
@@@@CABLLCOLO : CkSum = (207 + 48) Checksum OK.
G@@@@DBLLOELM : CkSum = (205 + 57) Checksum Fail.
IIIIIDAEBAOKF : CkSum = (182 + 73) Checksum OK.
@@@@@@AEBMNML : CkSum = (220 + 35) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BADODEL@ : CkSum = (192 + 63) Checksum OK.
IIII@D@E@MNKG : CkSum = (183 + 72) Checksum OK.
IIIIIA@EDNNJL : CkSum = (172 + 83) Checksum OK.
IIIIII@ECDDKI : CkSum = (185 + 70) Checksum OK.
IIIIII@EABLKE : CkSum = (181 + 74) Checksum OK.
IIIIII@EBBOKA : CkSum = (177 + 78) Checksum OK.
IIIIII@EBMAKD : CkSum = (180 + 75) Checksum OK.
IIIIII@EBDOJO : CkSum = (175 + 80) Checksum OK.
@@@BF@CNOE@MB : CkSum = (210 + 45) Checksum OK.
@@@@BECN@@MMJ : CkSum = (218 + 37) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BCLCOBKJ : CkSum = (186 + 69) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
Reading calibration data complete.
Invalid checksum during calibration data read!
CalEd: inst com checksum fail!
Abort: COM fail cal Checksum failed.
Exit cal update.
[...] I have been considering using the Pico board instead
an RPI would be more challenging to build and develop, since rpi need an OS to boot ... and you need to load plugins etc ..
I have users of my HP 3478A multimeter control software that are getting checksum errors when trying to read the calibration data. This is happening with newer AR488 firmware versions. Older firmware works fine.
Is there a particular reason why read_tmo_ms is limited to a maximum of 32,000 milliseconds? The code seems to handle the timeout as an unsigned long internally, allowing 4,294,967,295 milliseconds as the real maximum.
[...] I have been considering using the Pico board instead
did the idea of using a RPi pico ever go anywhere? looks like with some series resistors the signal level differences shouldn't be too much of an issue - or there are plenty of little level-shifter boards out there.
Well, it runs on a ESP32-S2 (see photo) with a minimum number of components!
That's the module, the connectors, some ESD protection and some passives to make the module happy.
I thought of doing an Ethernet version (maybe a port to a ch32v307).
The problem with this is, that you have to seriously think about locking/unlocking equipment (GPIB isn't that good with multiple-"masters" on the "bus"...).
Additionally, you'd need power.
BTW: if someone really plans to look into making a nice web-interface for the ESP32, I'd be open to send out 1 or 2 of my devices to help out with hardware... ideally within Europe to keep shipping costs reasonable
73
BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.
I do lots of web REST interfaces for the esp (8266 but I can move to esp32).
not graphical, but pure REST interfaces (gets and sets via simple routes or paths).
PM me if you want to discuss.
Well after a long spell of illness during December and most of January, I have finally managed to push the latest release out.
Is there a particular reason why read_tmo_ms is limited to a maximum of 32,000 milliseconds? The code seems to handle the timeout as an unsigned long internally, allowing 4,294,967,295 milliseconds as the real maximum.
It is limited by the int variable used to store its value in EEPROM. In the original code the limit was even smaller. When I extended it, I thought 30 seconds was reasonable and not likely to be exceeded. The reason why an unsigned long is being used in the handshaking routine is because the value is being compared to millis, which is also an unsigned long. I am not fortunate enough to have an 8-digit meter, but there is no reason why a larger variable could not be used in the config struct to accommodate longer time periods. Of course that would require re-saving of EEPROM contents.
BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.
Well, I made a pull request... https://github.com/douardda/AR488-ESP32/pull/1
My repo: https://github.com/WilheJo/AR488-ESP32
the way I'm doing my t/m remote control stuff is now focused on wifi REST calls for simple gets and sets. for that, you dont need esp32, esp8266 is more than enough. the only reason I'd HAVE to use a 32 is if I went with bluetooth for some reason. some lower cost meters use BLE as their remote control and for that the esp32 would be ideal.
the meters I'm more interested in are those that have serial interfaces. for that, software serial is more than enough for an esp class chip.
no usb wanted or needed. certainly not 'real' usb. usb-serial would be sort of ok, but micros usually cant do usb inputs, they are uart focused. so having serial wrapped in usb is overkill and not useful to me.
for streaming output, websockets are fine. espnow is also fine for some things (esp to esp comms).
but mostly I'm using just 'curl -s' to get and set things. start polling, stop polling, get values, set config, restore config, etc.
I have power supplies, meters, dc loads and planning other things that use this method of config/control.
(in my last several jobs, I got into the json religion and never looked back. connectionless fetches via REST are so simple and so fast, I dont see much need for other forms of remote control anymore)
I've been working on an api infra for all this so that the user only has to write a few lines to get all that up and running.
I do plan to release to my github but its not there yet, still under devel. but its been running for a while now (years) and its proven itself in my labs.
Just a script-set isn't really what you want/need... maybe as a start, but at some point, you want to have nice graphic.
there is no sign of the wemos d1 mini EVER going out of style in my timeframe (where I'd care). its a standard and its not going anywhere. the esp32 fans really crack me up. there's a place for both but to deny the older one makes no sense. the d1 mini footprint is de-facto and they are cheap as chips with next day delivery possible.
if you dont need ble, then there's no compelling reason to have to use esp32.
I have those chips at home but have not actually had the need to go beyond an 8266. seriously.
QuoteJust a script-set isn't really what you want/need... maybe as a start, but at some point, you want to have nice graphic.
I'm more about automation and so graphic and user-data fields and mousing is definitely not what I want. and not my focus at all. there are already too many graphical this and that and you can always make one IF you have a raw get/set interface that works.
json as the language and rest over port 80 as the transport is, again, a great way for automation to work network-wide.
before that, usb and serial to local systems made sense. gpib was like that, too. but now I see the world as networked and with things being able to send a get or set and get a simple ascii json reply back. if you give me that, I can do anything after that.
if you give me graphics and user clicky, I have no desire to try to automate it or even use it. just being honest.
so again, my focus is entirely on a sane remote api (json over rest) and while it wont be directly usable by scpi style clients, that's not a problem for me. I just want the timestamped data so that I can do things with it myself.
Well after a long spell of illness during December and most of January, I have finally managed to push the latest release out.
I'm sorry to hear that. I hope you are feeling a bit better now.
It is limited by the int variable used to store its value in EEPROM. In the original code the limit was even smaller. When I extended it, I thought 30 seconds was reasonable and not likely to be exceeded. The reason why an unsigned long is being used in the handshaking routine is because the value is being compared to millis, which is also an unsigned long. I am not fortunate enough to have an 8-digit meter, but there is no reason why a larger variable could not be used in the config struct to accommodate longer time periods. Of course that would require re-saving of EEPROM contents.
Thanks, but Gertjan's suggestion put me on the right track. I tell the meter to assert SRQ when it has a reading ready and then handle it with ++srqauto. Much more efficient!
BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.
Well, I made a pull request... https://github.com/douardda/AR488-ESP32/pull/1
My repo: https://github.com/WilheJo/AR488-ESP32
Indeed. I have discovered that David Douard has added the ESP32 (and STM32) layout configurations to the platformio.ini file. I can pick them up from there and add them to this project.
I do lots of web REST interfaces for the esp (8266 but I can move to esp32).
not graphical, but pure REST interfaces (gets and sets via simple routes or paths).
PM me if you want to discuss.
Additionally, this potential wifi-connection needs crypto.
There's no excuse to have some non-ssl service in 2024!
Well after a long spell of illness during December and most of January, I have finally managed to push the latest release out.
I'm sorry to hear that. I hope you are feeling a bit better now.
Thank you. Recovery has been a gradual recovery, but I am slowly getting there and almost back to a normal routine.It is limited by the int variable used to store its value in EEPROM. In the original code the limit was even smaller. When I extended it, I thought 30 seconds was reasonable and not likely to be exceeded. The reason why an unsigned long is being used in the handshaking routine is because the value is being compared to millis, which is also an unsigned long. I am not fortunate enough to have an 8-digit meter, but there is no reason why a larger variable could not be used in the config struct to accommodate longer time periods. Of course that would require re-saving of EEPROM contents.
Thanks, but Gertjan's suggestion put me on the right track. I tell the meter to assert SRQ when it has a reading ready and then handle it with ++srqauto. Much more efficient!
Fair enough.I am glad to hear that the SRQ feature is being used and is actually useful!BTW, I can add support for the ESP-S2 to my project. I just need the pinout details.
Well, I made a pull request... https://github.com/douardda/AR488-ESP32/pull/1
My repo: https://github.com/WilheJo/AR488-ESP32
Indeed. I have discovered that David Douard has added the ESP32 (and STM32) layout configurations to the platformio.ini file. I can pick them up from there and add them to this project.
I have now retrospectively added the ESP32 pinout configurations from the forked projects to this project. It should be noted however, that David Douard's version has flags to enable use of PSRAM and the built-in Bluetooth feature on the ESP32, which I have not implemented yet.I do lots of web REST interfaces for the esp (8266 but I can move to esp32).
not graphical, but pure REST interfaces (gets and sets via simple routes or paths).
PM me if you want to discuss.
I did consider doing something with MQTT a while back. I had experimented with it for another project and it seemed useful, however that idea took a back seat. In any case, it would require an MQTT broker, e.g. running on a Pi or on the PC which adds a little complexity. I haven't really worked with RESTful APIs yet. Interesting idea though.Additionally, this potential wifi-connection needs crypto.
There's no excuse to have some non-ssl service in 2024!
I tend to agree, even did back in 2020 when I first had a look at this. At the time it was feasible to set up a HTTPS server on an ESP32. It is a bit more complex because you have to create and set up an SSL certificate, but it does work. Encryption is expected these days. Unfortunately, at the time, unlike the ESP8266, the ESP32 SDK did not appear to have a native WebServerSecure library, only WebServer which was clear text. A third party library called esp_https_server library was available and could be used but was still in development. The syntax and methods were different from the ESP8266 version, so the code ended having to be almost totally re-written to work on the ESP32. Eventually I ended up with a working prototype (2 or 3 actually), but it felt rather less responsive to requests than the equivalent running on the ESP8266, which is odd since the ESP32 has hardware to run the encryption, whereas the ESP8266 had to do this in software. I plan to re-visit HTTPS on the ESP32 in the not too distant future.
Wolfssl sems to be able to create self signs certificates on fly.
So you could have a partition holding certs for the IP addresses you get via DHCP...or the new key algorithms you get via updates.
Anyhow, I still would opt for a transparent (web)socket.
This would allow the existing software to use this minimal (if at all) changes.
I mean redirecting serial data via some TCP socket is nothing new...
Hello, newly registered here....i have some old hp test equipment..8903b, 3478a and lots more, i came across the ar488 and built one based on the arduino nano. I want to use labview (community edition) and found that the prologix labview example did not work at all, i could not find much information on ar488 combined with labview. I debugged it and found that on connection the arduino resets itself, this is by design in order to program it from the arduino IDE but the labview code does not see anything returned after a command is sent because the nano is restarting during the time the command is sent and does not "see" it. This can be solved by adding a little delay after the opening of the visa device in labview. Maybe something to add to the readme of the ar488 code.
I have users of my HP 3478A multimeter control software that are getting checksum errors when trying to read the calibration data. This is happening with newer AR488 firmware versions. Older firmware works fine.
AR488 GPIB controller, ver. 0.49.14, 02/03/2021
Reading calibration data.
**********
Verify checksums.
@@@CA@BLLLNLG : CkSum = (199 + 56) Checksum OK.
@@@@CABLLCOLO : CkSum = (207 + 48) Checksum OK.
@@@@@DBLLOELM : CkSum = (205 + 50) Checksum OK.
IIIIIDAEBAOKF : CkSum = (182 + 73) Checksum OK.
@@@@@@AEBMNML : CkSum = (220 + 35) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BADODEL@ : CkSum = (192 + 63) Checksum OK.
IIII@D@E@MNKG : CkSum = (183 + 72) Checksum OK.
IIIIIA@EDNNJL : CkSum = (172 + 83) Checksum OK.
IIIIII@ECDDKI : CkSum = (185 + 70) Checksum OK.
IIIIII@EABLKE : CkSum = (181 + 74) Checksum OK.
IIIIII@EBBOKA : CkSum = (177 + 78) Checksum OK.
IIIIII@EBMAKD : CkSum = (180 + 75) Checksum OK.
IIIIII@EBDOJO : CkSum = (175 + 80) Checksum OK.
@@@BF@CNOE@MB : CkSum = (210 + 45) Checksum OK.
@@@@BECN@@MMJ : CkSum = (218 + 37) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BCLCOBKJ : CkSum = (186 + 69) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
Reading calibration data complete.
Calibration data checksum valid.
Calibration data saved to:D:\HP3478A_6\cfg\HP3478A.cal
#################################################
AR488 GPIB controller, ver. 0.51.18, 26/02/2023
Reading calibration data.
**********
Verify checksums.
@@@CA@BLLGNLG : CkSum = (199 + 51) Checksum Fail.
@@@@CABLLCOLO : CkSum = (207 + 48) Checksum OK.
G@@@@DBLLOELM : CkSum = (205 + 57) Checksum Fail.
IIIIIDAEBAOKF : CkSum = (182 + 73) Checksum OK.
@@@@@@AEBMNML : CkSum = (220 + 35) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BADODEL@ : CkSum = (192 + 63) Checksum OK.
IIII@D@E@MNKG : CkSum = (183 + 72) Checksum OK.
IIIIIA@EDNNJL : CkSum = (172 + 83) Checksum OK.
IIIIII@ECDDKI : CkSum = (185 + 70) Checksum OK.
IIIIII@EABLKE : CkSum = (181 + 74) Checksum OK.
IIIIII@EBBOKA : CkSum = (177 + 78) Checksum OK.
IIIIII@EBMAKD : CkSum = (180 + 75) Checksum OK.
IIIIII@EBDOJO : CkSum = (175 + 80) Checksum OK.
@@@BF@CNOE@MB : CkSum = (210 + 45) Checksum OK.
@@@@BECN@@MMJ : CkSum = (218 + 37) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
IIIE@BCLCOBKJ : CkSum = (186 + 69) Checksum OK.
@@@@@@@@@@@OO : CkSum = (255 + 0) Checksum OK.
Reading calibration data complete.
Calibration data not saved. Invalid checksum!
The problem is still there with 0.51.28. It's very specific. You get a checksum error on the first and third cal entries.