Anyone have an HP / Agilent E1406A VXI controller with IBASIC?

[gslick]

Does anyone have an HP / Agilent E1406A VXI controller with the optional IBASIC (Instrument BASIC) installed? If so, was it factory installed, or is there some way it can be user installed?

I have a newer style surface mount version Agilent E1406A, which has 1.75MB FLASH and 2MB RAM in addition to the 256KB boot ROM (actually FLASH which has no provision to write). This appears that it should be equivalent to the older through-hole version with the expanded memory option 010 installed.

I believe the IBASIC option would be installed in the FLASH, which can be user updated through the GPIB or serial interface. If someone has an E1406A with the optional IBASIC installed I wonder if the IBASIC could be uploaded out of the FLASH and downloaded into another E1406A which does not have IBASIC installed.

This is currently what I see in the E1406A that I have:

Code: [Select]

DIAG:DRIVER:LIST:ROM?
SYSTEM,E1406A,A.09.00,ROM;
UNKNOWN,UNKNOWN,0,ROM;
VOLTMTR,E1326A,A.05.01,ROM;
SWITCH,SWITCHBOX,A.07.00,ROM;
COUNTER,E1332A,A.04.02,ROM;
COUNTER,E1333A,A.04.02,ROM;
DIG_I/O,E1330A,A.04.04,ROM;
D/A,E1328A,A.04.02,ROM

DIAG:DRIVER:LIST:FROM?
ALG_CTL,E1415/19,A.05.13,FLASH;
ARB,E1340A,A.01.02,FLASH;
DIG_IO,DIG_IO,A.05.04,FLASH;
E1339A,E1339A/Z2309A,A.04.01,FLASH;
E1418,E1418,A.01.05,FLASH;
SCAN_AD,E1413,A.09.00,FLASH;
SWITCH,SWITCHBOX,A.11.01,FLASH;
RFMUX80,E1470A,A.01.01,FLASH;
VOLTMTR,E1326A,A.08.01,FLASH

SYSTEM:VERSION?
1990.0


[gslick]

No one ever replied to this post so maybe no one else out there on the forum uses HP / Agilent E1406A VXI controllers, or knows anything about them. Or maybe some do, but didn't know the answer to the IBASIC (Instrument BASIC) question.

As a follow up over a year later just in case anyone else has the same question about installing IBASIC on an E1406A which doesn't have it installed, I finally looked in the right place to find a copy of the "ibA.09.01" system ROM image file for the E1406A which includes IBASIC.

It is a 1MB binary image file that can be downloaded to an E1406A using the PROGRAM:DELETE and PROGRAM:DEFINE commands when it is switched into Loader mode. That replaces the 768KB system ROM image that doesn't contain IBASIC. The Flash ROM (FROM) space available for downloading D-SCPI drivers is then reduced from 1MB to 768KB, and any drivers which were previously downloaded into FROM space will need to be downloaded again. (There are no ROM devices on the E1406A PCB, they are all Flash devices, just logically partitioned into separate areas).

After downloading the "ibA.09.01" system ROM image file to an E1406A this is the driver list in ROM space. The SYSTEM was updated from A.09.00 to A.09.01, and IBASIC A.04.02 is now present.

Code: [Select]

DIAG:DRIVER:LIST:ALL?
SYSTEM,E1406A,A.09.01,ROM;
IBASIC,IBASIC,A.04.02,ROM;
VOLTMTR,E1326A,A.05.01,ROM;
SWITCH,SWITCHBOX,A.07.00,ROM;
COUNTER,E1332A,A.04.02,ROM;
COUNTER,E1333A,A.04.02,ROM;
DIG_I/O,E1330A,A.04.04,ROM;
D/A,E1328A,A.04.02,ROM

[mcguire]

As per our private email, thanks Glen, I'll be trying that this weekend!

I drive my VXI systems from a V743, which is an HP9000 series 700 on a VXI module.  It's great, I love working with it.  I do both hobby and business stuff with it; most recently I built an ATE system for a production line with it.  It works great, costs very little, requires no maintenance, and a closet full of spares costs almost nothing.

I've done the same with a V382, but most of my work has been on V743s of late.

                    -Dave

[Tony_G]

Just out of interest, how do you handle the video out from the device? I have a viper card that I use but I've always thought about putting a small VXI enclosure in my rack instead but never really done much research on it.

TonyG

[gslick]

The E1497A V743/64 is a 64 MHz 7100LC PA-RISC processor VXI embedded controller.
The E1498A V743/100 is a 100 MHz 7100LC PA-RISC processor VXI embedded controller.
The E1499A V382 is an MC68040 processor VXI embedded controller.
They all have standard VGA type video output, although the connectors on the V743 are not so common Micro-D ? connectors.

The E1406A VXI controller has no video capability, only text through the RS-232 port, so you couldn't run any Basic programs which used graphic modes.

[gjcrooks]

I have a couple of E1406A cards and would like to add IBASIC. Can you tell me where I can download the system image ROM? I have tried searching Keysight and a general google search but have not come up with any relevant hits.

[gslick]

I have a couple of E1406A cards and would like to add IBASIC. Can you tell me where I can download the system image ROM? I have tried searching Keysight and a general google search but have not come up with any relevant hits.

Thank the Internet Archive, that's where I finally found it after thinking to look there. This used to be available on the Keysight FTP site before they scrubbed most of the useful stuff.

Go here: https://archive.org/download/ftp.keysight.com/

Click on the 2015.03.ftp.keysight.com.tar "View Contents" link.

Then search down to the ftp.keysight.com/mpusup/vxi/E1406/ links.

Then download these two binary files:
ftp.keysight.com/mpusup/vxi/E1406/ibA.09.01
ftp.keysight.com/mpusup/vxi/E1406/nibA.09.01

The ibA.09.01 file is a 1MB binary "ROM" image which contains IBASIC.

The nibA.09.01 file is a 768KB binary "ROM" image which does not contain IBASIC in case you wanted to remove IBASIC for some reason, or needed the extra 256KB of FLASH space for downloaded drivers.

To update the E1406A "ROM" flip the front panel switch into the Load position before powering on or resetting the E1406A, and then you can use the PROG:DEL and PROG:DEF commands over the GPIB port to download the "ROM" image into the flash.

For example to download the 1MB ibA.09.01 file, cat the string "PROG:DEL;DEF #801048576" plus the contents of the ibA.09.01 file plus an LF terminator character and send that to the E1406A GPIB port.

That wipes both the "ROM" and "FLASH" space so if you have any downloaded drivers to "FLASH" space you'll have to download them again.

The docs say you need to have the extra memory option 010 in the E1406A to use IBASIC. The standard version of the  E1406A has 512 KB of RAM and 1.25 MB of Flash ROM. The Option 010 version provides 1 MB of RAM and 1.75 MB of Flash ROM.

E1406A products manufactured before May 2002 and with serial numbers lower than US41000101 were thru hole boards. Two boards were present and consisted of a main PCA, E1406-66501, plus a memory PCA which was either the E1406-66502 standard memory board or the E1406-66503 option 010 max memory board.

E1406A products with serial numbers greater than US41000101 contain only one board, E1406-66511. This is a surface mount board with maximum memory.

The two E1406A modules that I have that I updated with the IBASIC ROM image are the newer thru hole version with the max memory. I don't know if the IBASIC ROM image would work on an older standard version without the Option 010 memory. Maybe it does actually "work", but with some limitations due to less RAM, and also less Flash is available for downloading additional instrument drivers that are not present the IBASIC ROM image, or downloading newer versions of instrument drivers that are present in the IBASIC ROM image.

[gjcrooks]

Thanks for your prompt and informative response. I have found and downloaded both files. Unfortunately both of my cards are the 512kB versions so I guess this may not work. If I try and it fails do you know if I can revert to the non-IBASIC version easily?

Mine are currently running 09.00 so I would probably like to update to 09.01 even if I can't have the IBASIC version. Can I ask how you sent the command, file and LF terminator to the unit? I have controlled the unit with commands manually and I have written some programs to automate control of other cards through these units. I guess I could write a program to read the firmware into a variable and then send "PROG:DEL;DEF #801048576" & $file & CHR(10)?

The main reason I was looking to add IBASIC is I need to assign additional logical addresses to a VXI card. The card has three consecutive addresses so cannot be accessed through this GPIB controller as they cannot all be divisible by 8. I was hoping to set the card to 28, 29 & 30 and then map these to 24, 32 & 40. I have looked at the manual and the example given to do something similar is written in IBASIC. I have tried reverse engineering to produce a command I can send via GPIB but so far no success. This is what I have tried:

DIAG:BOOT:COLD
DIAG:NRAM:CRE 20
DIAG:BOOT:WARM
DIAG:NRAM:ADDR? ; returns MADDR=16252928
DIAG:DOWN 16252928 ,#00000000100000011,0000000000011100,0000000000000000,0000000000011000,0000000000011101,0000000000000000,0000000000100000,0000000000011110,0000000000000000,0000000000101000
VXI:CONF:CTAB 16252928
DIAG:BOOT:WARM

The DIAG:DOWN line causes a SYSFAIL and I am struggling to see why. The IBASIC source is:
240 DATA 259,28,0,24,29,0,32,30,0,40
250 READ Cs_hier(*)
260 OUTPUT @E1406 USING "#,3(K)";"DIAG:DOWN";A;" ,#0"
270 OUTPUT @E1406 USING "W";Cs_hier(*)

which as I read it sends DIAG:DOWN followed by the memory address (A) followed by " ,#0" (Indefinite length data block) followed by the data held in Cs_hier as comma separated 16-bit twos complement. I have tweaked the original DATA to match my needs; 257 became 259 as I have 3 table entries rather than 1; 25,0,1 became 28,0,24,29,0,32,30,0,40 for my 3 table entries.

Any help greatly appreciated.

[gslick]

I used Python and PyVISA on a Windows PC to download the ibA.09.01 system "ROM" image to the E1406A.

I first created a hdr.txt header file containing the text "PROG:DEL;DEF #801048576", where the "#8" is the length of the byte count string, and the "01048576" is the byte count string. The size of the ibA.09.01 system "ROM" image file is 1MB or 1,048,576 bytes. I also created an lf.txt file containing a single LF (0x0A) character. Then I binary concatenated the 3 files together "copy /b hdr.txt + ibA.09.01 + lf.txt program.bin". That resulted in a program.bin file of size 1,048,600 bytes.

Then I used this quick and dirty Python / PyVISA code to download the resulting program.bin file to the E1406A. One important thing is setting an appropriate command timeout. Programming the flash takes a while. I forget how long, maybe a couple of minutes. You don't want the VISA library to timeout in the middle of updating the flash. It is not fatal if the runtime system flash gets corrupted because the loader code is in a read-only section of flash.

The instrument ID is "LOADER" when the E1406A is powered on or reset with the switch in the Load position.

If I was going to spend more time on this I could have added code to write the command header at runtime instead of manually adding it to the file before downloading it.

Code: [Select]

import visa
from datetime import datetime, date, time

starttime = datetime.now()

ResourceManager = visa.ResourceManager()
Resources = ResourceManager.list_resources()

FoundTarget = False

for Resource in Resources:
    Instrument = ResourceManager.open_resource(Resource)
    try:
        InstrumentId = Instrument.query("*IDN?")
    except visa.VisaIOError as Error:
        print("query", Resource, Error.description)
    else:
        print("InstrumentId", Resource, InstrumentId[:-1])
        if "LOADER" in InstrumentId:
            FoundTarget = True
            TargetInstrument = Instrument
            print("Found Target", Resource, InstrumentId[:-1])
            break
        else:
            Instrument.close()

if FoundTarget:
   
    with open("program.bin", "rb") as f:
        bytes = f.read()
        TargetInstrument.timeout = 600000
        byteswritten = TargetInstrument.write_raw(bytes)
        print("Bytes written ", byteswritten)
    TargetInstrument.close()

endtime = datetime.now()
print("Elasped time:", endtime - starttime)

Before updating the system "ROM" image the current image can be read from the E1406A using the "PROGRAM:DEFINE?" command. For example using the quick and dirty code such as this:

Code: [Select]

import visa
from datetime import datetime, date, time

starttime = datetime.now()

ResourceManager = visa.ResourceManager()
Resources = ResourceManager.list_resources()

FoundTarget = False

for Resource in Resources:
    Instrument = ResourceManager.open_resource(Resource)
    try:
        InstrumentId = Instrument.query("*IDN?")
    except visa.VisaIOError as Error:
        print("query", Resource, Error.description)
    else:
        print("InstrumentId", Resource, InstrumentId[:-1])
        if "E1406A" in InstrumentId:
            FoundTarget = True
            TargetInstrument = Instrument
            print("Found Target", Resource, InstrumentId[:-1])
            break
        else:
            Instrument.close()

if FoundTarget:
    TargetInstrument.write("PROGRAM:DEFINE?")
    bytes = TargetInstrument.read_bytes(1048576+10)
    with open("firmware.bin", "wb") as f:
        f.write(bytes)
    TargetInstrument.close()

endtime = datetime.now()
print("Elasped time:", endtime - starttime)

[gslick]

Back to your question about your actual goal of assigning logical addresses to VXI cards, that's not something I have any experience doing. I'll have to take a look at the manuals and see if I can figure out what might be going on there.

[gjcrooks]

Thanks for the information. I must admit I didn't know Python supported VISA but now that I do I think we will be becoming better acquainted. I will try upgrading one of my 512kB cards with the IBASIC ROM and let you know if it works.

I had forgotten about using copy /b to binary combine files. I am wondering if this is the answer to my other problem. I will try creating a binary file with the table information and then binary combine it with the commands. I can then use your Python script to send it to the card - I may need a slight tweak to the ID as I don't think it needs to be in LOADER mode to make the change. To save you wasting your time reading manuals let me try this first and I will let you know how I get on - you have already been very generous to give up your time to assist me.

Have a great weekend.

[gjcrooks]

Good news - end goal achieved!

I created a binary table file and used copy /b to create a file to send via IEE using your python script. I had to tweak slghtly as my first try just mapped 1 port to GPIB address GPIB1::9::24::INSTR. The table maps to GPIB address not logical address. Having changed the mappings to 3, 4 & 5 everything now works perfectly.

I haven't tried the IBASIC firmware yet but will let you know how that goes.

Many thanks for your help as it pointed me in the right direction to resolve this.

[JimmyJimJames]

Thanks for all of the information on this thread (and sorry to revive it, but I'm running out of ideas).

Have any of you usd the old VXIDLD.EXE program and the RS232 interface to upload the new firmware?

That program is in the same https://archive.org/download/ftp.keysight.com/ directory:
https://web.archive.org/web/20040806112541/http://ftp.agilent.com/pub/mpusup/vxi/E1406/

I created a FreeDOS VirtualBox machine, and I've successfully used the VXIDLD.EXE program to load drivers to the E1406A (after reading the directions which say to copy only the .DC files I need into a separate directory with the VXIDLD files) but I cannot get the firmware to load.

There's some sort of weird naming convention, shown in the VXIDLD.CFG file, which I tried to follow, renaming the ibA.09.01 file to be IA09011.PC .  VXIDLD seems to find the file, but the program stops with the error saying: 
ERROR:  ROM program file 'IA09011.PC' is empty or not readable (file will not be used)

Any ideas?  I looked at the source in the VXIDLD.BAS and VXIDLD.GET files and sort of see that it's opening the file in binary mode and trying to read a character, making sure it's not a hex zero.  It looks like that is somehow failing.

Could the file not have been saved in binary mode from the archive site?  I do recall when using FTP, you had to specifically specify binary mode, but I don't see how to do that on the archive site.

EDIT: As a follow-up, I wrote a quick C program to read the first 20 characters from the ibA.09.01 file, and it shows the first character being a 0x00, which would make the code fail.

[gslick]

There's some sort of weird naming convention, shown in the VXIDLD.CFG file, which I tried to follow, renaming the ibA.09.01 file to be IA09011.PC .  VXIDLD seems to find the file, but the program stops with the error saying: 
ERROR:  ROM program file 'IA09011.PC' is empty or not readable (file will not be used)

Any ideas?  I looked at the source in the VXIDLD.BAS and VXIDLD.GET files and sort of see that it's opening the file in binary mode and trying to read a character, making sure it's not a hex zero.  It looks like that is somehow failing.

EDIT: As a follow-up, I wrote a quick C program to read the first 20 characters from the ibA.09.01 file, and it shows the first character being a 0x00, which would make the code fail.

The 1,048,576 byte (exactly 1MB) ibA.09.01 ROM file is a pure binary ROM image file.

The VXIDLD.BAS program appears to be set up to work with a ROM program file that contains a header section with the program download commands. It also uses the CHECked data format for download over a serial port, which uses one byte to send every 4 bits, with 1 control bit and 3 check bits for the 4 data bits, as documented in the Keysight E1406A Command Module, User Manual and SCPI Programming, E1406-90004.

If you want to use the VXIDLD.BAS program to download the main ROM image using the contents of the ibA.09.01 ROM file, you would need to prepend the expected program download command header, and translate each byte in the ROM image into two bytes in the CHECked data format. I'm not sure if inserting a \r character every 80 characters is necessary too.

GetPFInfo routine from VXIDLD.BAS:

Code: [Select]

SUB GetPFInfo
 '
 ' This subprogram gets information about the ROM program file.
 '
   DIM JunkByte AS STRING * 1,CheckByte AS STRING * 1,LenByte AS STRING * 1
   DIM Expect$
 'RS-232 control begins
     ' Program file format:
     '   CONTENTS                BYTES MEANING
     '   ----------------- --      -------------------------------
     '   CNTL-D 1 connect to display system (0x04)
     '   ST UNKNOWN\r 11 insure terminal control not used
     '   SI LOADER\r 10 connect to loader instrument
     '   *RST\r 5 device reset
     '   PROG:DEL;   9 SCPI command
     '   DEF:CHEC #8 11 SCPI command header
     '   dddddddd 8 (BS) size of data block, BS=2xROM
     '   ... N flash ROM code, N=BS+(BS/80)
     ' this includes \r every 80 chars
     '   <CR> 1 terminate command (0x0d)
     '
     Expect$=CHR$(04)+"ST UNKNOWN"+CHR$(13)+"SI LOADER"+CHR$(13)+"*RST"+CHR$(13)+"PROG:DEL;DEF:CHEC #8"
     CmdSize=LEN("PROG:DEL;DEF:CHEC #8")+8+1 'Cmd + 1 char fudge
 'RS-232 control ends
   '
   IF ""<>PFFName$ THEN
     BadFile=0 'FALSE
     ErrorOccured=0 'FALSE
     ON ERROR GOTO SetErrorOccured
     OPEN SeDir$+PFFName$ FOR BINARY AS #3
     GET #3,1,JunkByte$
     IF JunkByte$=CHR$(0) THEN ErrorOccured=1 'TRUE
     ON ERROR GOTO 0
     IF 0<>ErrorOccured THEN
       CALL ReportErr("ROM program file '"+SeDir$+PFFName$+"' is empty or not readable (file will not be used)")
       BadFile=1 'TRUE
     ELSE
       BlkLenStart=LEN(Expect$)
       PFPSize=0
       FOR I=1 TO 8
         GET #3,BlkLenStart+I,LenByte$
         IF "0">LenByte$ OR "9"<LenByte$ THEN
           BadFile=1 'TRUE
         ELSE
           PFPSize=10*PFPSize+VAL(LenByte$)
         END IF
       NEXT I
       'Compute the size of all ROM program parts based on block size
 'RS-232 control begins
         PFFSize=BlkLenStart+8+PFPSize+((PFPSize+CmdSize+1) \ 79)+1
 'RS-232 control ends
       ' Check that the file looks okay
       FOR J=1 TO LEN(Expect$)
         GET #3,J,CheckByte$
         IF MID$(Expect$,J,J-(J)+1)<>CheckByte$ THEN BadFile=1 'TRUE
       NEXT J
       IF 0<>BadFile THEN CALL ReportErr("ROM program file '"+SeDir$+PFFName$+"' is not in proper format (file will not be used)")
     END IF
     CLOSE #3
     IF 0<>BadFile THEN PFFName$=""
   END IF
 END SUB 'GetPFInfo

When I downloaded the ROM image using the contents of the ibA.09.01 ROM file, I did so over the GPIB port in plain binary format without using the CHECked data format, instead of over the serial port using the CHECked data format.

[JimmyJimJames]

There's some sort of weird naming convention, shown in the VXIDLD.CFG file, which I tried to follow, renaming the ibA.09.01 file to be IA09011.PC .  VXIDLD seems to find the file, but the program stops with the error saying: 
ERROR:  ROM program file 'IA09011.PC' is empty or not readable (file will not be used)

Any ideas?  I looked at the source in the VXIDLD.BAS and VXIDLD.GET files and sort of see that it's opening the file in binary mode and trying to read a character, making sure it's not a hex zero.  It looks like that is somehow failing.

EDIT: As a follow-up, I wrote a quick C program to read the first 20 characters from the ibA.09.01 file, and it shows the first character being a 0x00, which would make the code fail.

The 1,048,576 byte (exactly 1MB) ibA.09.01 ROM file is a pure binary ROM image file.

The VXIDLD.BAS program appears to be set up to work with a ROM program file that contains a header section with the program download commands. It also uses the CHECked data format for download over a serial port, which uses one byte to send every 4 bits, with 1 control bit and 3 check bits for the 4 data bits, as documented in the Keysight E1406A Command Module, User Manual and SCPI Programming, E1406-90004.

If you want to use the VXIDLD.BAS program to download the main ROM image using the contents of the ibA.09.01 ROM file, you would need to prepend the expected program download command header, and translate each byte in the ROM image into two bytes in the CHECked data format. I'm not sure if inserting a \r character every 80 characters is necessary too.

<snip>

When I downloaded the ROM image using the contents of the ibA.09.01 ROM file, I did so over the GPIB port in plain binary format without using the CHECked data format, instead of over the serial port using the CHECked data format.

Thank you for the reply.  For some reason I didn't think about the CHECKed format applying to the ROM images.  Duh.

The only functional way that I've been able to load the D-SCPI drivers to the E1406A for the cards in the system, is using a DOS Virtual Machine with the VXIDLD.EXE program, communicating to the serial port.  The VXIDLD.EXE program is also supposed to transfer the firmware files, but I guess that I need a firmware file version for the serial port transfer, like we have the .DC format driver files for serial port transfer, versus the .DU format driver files used for the GPIB interface.

I didn't intend to use the .BAS file, nor do I have a BASIC interpreter, but I just wanted to use the existing VXIDLD.EXE program, and figured the .BAS file gave me insight into the operation.

I've never worked with VXI equipment before, and I finally got a functional E1406A controller card out of the three used ones we purchased.  (Bad GPIB buffer chip on one, seemingly bad RAM/Flash on the other.)  All of them only have version 9.00 firmware:
HEWLETT-PACKARD,E1406A,0,A.09.00

When I still had the E1406A with the bad GPIB buffer and needed to use the serial port, I had a weird problem where I was unable to communicate to the E1441A ARB cards via the serial interface (using SI and SA commands) but could get to two other types of cards.  I was hoping that the firmware update would fix this issue, but since I now have a card with functional GPIB, I probably won't try to load 9.01 onto the card, especially if I have to convert the file to a different format.

[a100man]

For the benefit of anyone who is reading this thread, I'd like to mention that there is a VISA based download utility for downloading DSCPI drivers to Flash and to RAM. This works on modern systems quite well. It can be found in the archive mentioned earlier at
 ftp.keysight.com/mpusup/E1406A/visadownload/visaDownload.cab

I also have a question regarding the Memory usage of the E1406A with IBasic installed. I picked up up an Option 020 module and it has IBasic installed, with the larger Flash ROM, but the RAM only reports about 327kB (DIAG:DRAM:CRE? MAX,MAX) with no other instruments installed. I thought it should be close to 1MB. As there is plenty of Flash for my drivers, I would not care much, but it seems this RAM is also needed to support running the instruments. It seems that about 64kB is needed for each register based instrument , so as it is it could not support a full 13 slot mainframe. Does the "Ibasic instrument" consume the extra RAM that should be installed? Or is it possible that some of the RAM is bad? I would think the self test would fail in that case. If someone else who has a similarly configured card could let me know what they get from "DIAG:DRAM:CRE? MAX,MAX" with no other instruments I would appreciate that!

[a100man]

I took apart the module and discovered that all the RAM was present, but JM5 was set which specified 0.5M RAM. When I changed it to JM3 (1.0M) all the RAM was able to be seen. So either the module was mis-configured from the factory, or the OPT 020 didn't include OPT 010.