From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

TNT4882 - finding it from MAX

I did the sequence like you asked. after ibgts 0, i now get with iblines < >. basically nothing.

suppose I do have problems reading registers from the tnt4882, how does this effect the fact that I can't find the device from the controller side. I thought this is suppose to be done automatically between the tnt4882 and the controller.
0 Kudos
Message 31 of 65
(1,868 Views)
A few more tests. I think we are almost there.

Test 1: First, close ibic. Then in MAX, right-click on the GPIB controller and select properties. Set the primary address to 5 and click ok. Then, do a scan for instruments.

Test 2: Write to and then read from each of the TNT count registers (0x14, 0x16, 0x09, and 0x0B). Write a unique value to each and then read the register you just wrote. For example, write 0x11 to CNT0, 0x22 to CNT1, and so on.
0 Kudos
Message 32 of 65
(1,864 Views)
ok

1. I changed the controller to primary addres 5, and yes, now I am finding an instrument at primary address 0, which did not respond to #IDN?

2. I checked all 4 registers: wrote and read every single one
0 Kudos
Message 33 of 65
(1,861 Views)
Ok, the instrument you found at primary address 0 while scanning for instruments is the TNT. For some reason your write to ADR0 to set the primary GPIB address is not working. When the controller scans for instruments, it scans at every GPIB address except its own GPIB address. The default address of the GPIB controller is 0 and the default address of the TNT4882 is 0. The TNT is correctly accepting command bytes. With the GPIB controller still set to GPIB address 5 you can send ibmcd "\x20" which should cause the TNT to become a listener. You can check this in the ADSR.

In response to your writing/reading the CNT registers, can you confirm that you wrote a different value to each CNT register, and read that same value? I need to double check as that is very important.

You have the following line of code in your firmware

TNT4882[R_adr]=inSW; //read GPIB address and write it to ADR0

Where is inSW defined? Can you change this to a constant (0x03)?
0 Kudos
Message 34 of 65
(1,857 Views)
Yes, I wrote 0x11, 0x22, 0x33, 0x44 and I read all of them back.

inSW is a macro defined in another file whcih inputs DIP switches connected to some of the gpio pins of the DSP. that call is working properly. it is reading 0x03 from the switches and puting in to the ADR0 register.

one thing I should mention just to be on the safe side. I have a 16 bit data bus between the tnt4882 and the DSP. I have the pins ABUSEN set to '1' and BBUSEN set to '0'. so I should be using FIFOB (D7-D0), which is what I am getting when reading the 16 bit data bus. the only thing is that sometimes I get for the D15-D8 0x00, and sometimes I get 0xFF. for example: reading the counter registers, I read back 0xFF11, 0xFF22, 0xFF33, 0xFF44. some other registers I will have zeros for the 8 upper bits. I never considered this to be a problem because I am only looking at the 8 lsb anyway.
0 Kudos
Message 35 of 65
(1,856 Views)
If you have ABUSN unasserted (tied to VCC) and BBUSN asserted (tied to GND) then using D7:0 is correct. Do your writes from the DSP also use D7:0?

I see in your code that you read ADR0 immediately after writing it. Are you reading 0x3 from ADR0?
0 Kudos
Message 36 of 65
(1,851 Views)
Yes, I use the 7 lsb of the bus to write to the tnt4882 registers also.

Yes, I am reading 0x0003 when I am reading ADR0 reight after I set ADR to address 3
0 Kudos
Message 37 of 65
(1,850 Views)
Can you try reading ADR0 after the the controller has sent command x23?
0 Kudos
Message 38 of 65
(1,848 Views)
OK, I think I have a technical problem with reading ADR, when it is not right after setting it to 0x03. the reason is the ARS bit determines the selection between ADR0 and ADR1. that bit is set to 1 because the last time I accessed this register I had to disable the secondary address. How do I set the ARS bit back to 0 with out changing the ADR0 register while doing it. it turns out, that I basically have to write 0x03 again into ADR (ADR0 also) to switch to ADR0 and not to overwrite the address already in there. So in essense, I am rewriting 0x03 into ADR0 and only then reading it back. when I do that, after I send the ibcmd "\x23" I still obviously read 0x03.
0 Kudos
Message 39 of 65
(1,829 Views)
ADR is a little tricky.

There is a writable register at offset 0x0C. This register is called ADR. This single register actually maps to two different internal registers, ADR0 and ADR1. The specific register to which ADR maps during writes depends on ARS, bit 7. When you write the ADR with ARS set to 0, the write is mapped to ADR0. When you write the ADR with ARS set to 1, the write is mapped to ADR1.

ADR0 and ADR1 can be read. The ARS bit is not involved with reading ADR0 and ADR1, as ADR0 and ADR1 have different register offsets.

So, when writing the primary GPIB address to ADR0, you should be writing 0x03 (ARS is 0) to offset 0x0C. To disable the secondary address, write 0xE0 (ARS is 1) to offset 0x0C.

To read ADR0 simply read offset 0x0C, it should be 0x03. To read ADR1 simply read offset 0x0E, it should be 0x60. Again, you do not use ARS when reading either ADR0 or ADR1.
0 Kudos
Message 40 of 65
(1,826 Views)