"Scan For Instruments" process in GPIB USB-HS connection with STM32 GPIB DEVICE

[dogutuncr]

I am developing a device that can work with STM32 and GPIB IEEE 488.2 protocol. I can communicate with the Keysight 82357B USB-GPIB module with SCPI commands. Hence “*IDN?” and my device appears correctly with its name, model and version in the Keysight interface. However, when I run the "Scan for Instruments" command with the NI GPIB-USB-HS module and NI MAX interface, my device cannot be found. I used the following code block to solve this problem:

void SCAN_FOR_INSTRUMENTS(void)
{
	if(ATN_READ() == 0)											//If ATN is logic LOW
	{
		NDAC_DRIVE_LOW();										//Pull NDAC to LOW
		if(REN_CONTROL(false))									//Wait until REN is LOW (5s timeout)
		{
			while(1)
			{
				if(ATN_CONTROL(false))							//Wait until ATN is LOW (5s timeout)
				{
					NDAC_DRIVE_LOW();							//Pull NDAC to LOW
					NRFD_LEFT_FLOAT();							//Release NRFD

					if(DAV_CONTROL(false))						//Wait until DAV is LOW (5s timeout)
					{
						NRFD_DRIVE_LOW();						//Pull NRFD to LOW

						packetCounter++;
						GPIB_Packet[packetCounter] = DIO_READ();

						switch(GPIB_Packet[packetCounter])		//Analyze incoming data
						{
							case 0x3F:	//"UNL"
								delay_us(100);
								NRFD_DRIVE_LOW();				//Pull NRFD to LOW
								NDAC_LEFT_FLOAT();				//Release NDAC
								break;
							case 0x5F:	//"UNT"
								delay_us(100);
								NRFD_DRIVE_LOW();				//Pull NRFD to LOW
								NDAC_LEFT_FLOAT();				//Release NDAC
								break;
							case 0x20:	//"MLA0"
								osDelay(1);
								NRFD_DRIVE_LOW();				//Pull NRFD to LOW
								NDAC_DRIVE_HIGH();				//Pull NDAC to HIGH
								DAV_CONTROL(true);				//Wait until DAV is HIGH (5s timeout)
								NDAC_DRIVE_LOW();				//Pull NDAC to LOW
								ATN_CONTROL(true);				//Wait until ATN is HIGH (5s timeout)
								break;
							case 0x21:	//"MLA1"
								osDelay(1);
								NRFD_DRIVE_LOW();
								NDAC_DRIVE_HIGH();
								DAV_CONTROL(true);
								NDAC_DRIVE_LOW();
								ATN_CONTROL(true);
								break;
							case 0x22:	//"MLA2"
								osDelay(1);
								NRFD_DRIVE_LOW();
								NDAC_DRIVE_HIGH();
								DAV_CONTROL(true);
								NDAC_DRIVE_LOW();
								ATN_CONTROL(true);
								break;
							case 0x23:	//"MLA3"
								osDelay(1);
								NRFD_DRIVE_LOW();
								NDAC_DRIVE_HIGH();
								DAV_CONTROL(true);
								NDAC_DRIVE_LOW();
								ATN_CONTROL(true);
								break;
							case 0x24:	//"MLA4"
								osDelay(1);
								NRFD_DRIVE_LOW();
								NDAC_DRIVE_HIGH();
								DAV_CONTROL(true);
								NDAC_DRIVE_LOW();
								ATN_CONTROL(true);
								break;
							case 0x25:	//"MLA5"
								osDelay(1);
								NRFD_DRIVE_LOW();
								NDAC_DRIVE_HIGH();
								DAV_CONTROL(true);
								NDAC_DRIVE_LOW();
								ATN_CONTROL(true);
								break;
//My Device PAD is 6
							case 0x26:	//"MLA6"
								DAV_CONTROL(true);
								ATN_CONTROL(true);
								NRFD_DRIVE_LOW();
								NRFD_LEFT_FLOAT();
								NDAC_DRIVE_LOW();
								A_FLAG = true;
								break;
								
							case 0x3E:	//"MLA30"
								DAV_CONTROL(true);
								ATN_CONTROL(true);
								NDAC_LEFT_FLOAT();
								break;/*
							case 0x04:	//"SDC"
								NRFD_LEFT_FLOAT();
								DAV_CONTROL(true);
								NDAC_LEFT_FLOAT();
								break;
							case 0x40:	//"MTA0"
								NRFD_LEFT_FLOAT();
								DAV_CONTROL(true);
								NDAC_LEFT_FLOAT();
								break;*/
							default:
								NRFD_DRIVE_LOW();
								NDAC_LEFT_FLOAT();
						}

					}
					else
						NRFD_DRIVE_HIGH();
				}
				else											//ATN, 5sn boyunca LOW'a düşmemiştir
				{
					if(!A_FLAG)
						NDAC_DRIVE_HIGH();
					else
						A_FLAG = false;

					if(REN_READ() == 1)
					{
						GPIB_RESET();
						return;
					}
				}
			}
		}
		else													//REN, 5sn boyunca LOW'a düşmemiştir
		{
			GPIB_RESET();
			return;
		}
	}
}

First, I question whether ATN is in LOW. If ATN is LOW, I pull the NDAC pin to LOW and wait for the REN pin to become LOW (for 5 seconds).

If REN is LOW, I run the "Scan for Instruments" process in an infinite loop (while(1)).

In this process, I check each time whether the ATN pin is LOW (for 5 seconds). If it is LOW, I configure the NDAC pin as LOW (OUTPUT) and the NRFD pin as FLOAT (INPUT NOPULL).

Then I control the DAV pin to go LOW (for 5 seconds).

If DAV is LOW, I pull the NRFD pin to LOW and throw the incoming data into an array.

I analyze the incoming data (switch()) and perform the relevant operations. However, if the incoming data is "MLA6", I expect DAV to be HIGH. After DAV is HIGH, I expect ATN to be HIGH. If ATN is HIGH, I give a trig to the NRFD pin and pull the NDAC pin to LOW. At the end of the process, I wait for the ATN to be HIGH and complete the process. But I don't know what to do from here.

When I researched resources on the internet, I found that the "Scan for instruments" process performs the following operations. But I couldn't find the information I was looking for:

1. NI-VISA uses a FindLstn() test and an *IDN? to detect the connected GPIB device. performs the query.
2. If the device is SCPI compliant, it appears as GPIB::<primary address>::INSTR under the GPIB controller resource on MAX.

After the MLA30 data arrives, I receive the "Too Many Listener" warning on NI MAX and the question "*IDN?" The query does not come.

Where am I making mistakes?

Thanks.

Dogu.

[daliar@bynet-ts.co.il]

Hi Dogu, 

I'm not a GPIB expert, but let me try to help you to find the solution. 

Honestly, I dont know what the Scan for instrument does behind the hoods, but you can see the GPIB functions (ib functions) by running the IO Trace (NI-SPY) at the same time you press the Scan for instruments. 

Debugging with NI IO Trace

This way, you can see what really happens when pressing the Scan for Instruments.

Basically, NI-VISA calls the low-level GPIP API. 

Let's leave NI MAX for a moment.

Which programming language are you using? CVI, C++, C#? 

Looking at your code, it looks is CVI or C. 

Open a new project which it will behave as the client PC, this means that this problem will use the USB-GPIB to communicate with your chip. add the following code

			viOpenDefaultRM (&defaultRM);
			GetCtrlVal (panelHandle, PANEL_RESOURCE, resource);
			viOpen (defaultRM, (ViRsrc)resource, VI_NULL, VI_NULL, &instrHandle);
			viSetAttribute (instrHandle, VI_ATTR_TMO_VALUE, 10000);
			commandString ="*IDN?"
			length = StringLength (commandString);
			viWrite (instrHandle, commandString, length, &RTCount);
			count = 100 /*Bytes to count*/
			Databuf[0] = '\0';
			viRead (instrHandle, Databuf, count, &RTCount);
			Databuf[RTCount] = '\0';
			ResetTextBox (panelHandle, PANEL_READ, "");
			SetCtrlVal (panelHandle, PANEL_READ, Databuf);
			viClose (instrHandle);
			viClose (defaultRM);

Note.- I'd attached the CVI code. It comes from the CVI Core1 course. If you are using C, avoid the SetCtrlVal and GetCtrlVal

The goal is to send the SCPI command "*IDN?" directly and read it back.

You can run the IO Trace in parallel. 

I hope these suggestions will help. 

Regards

Dalia

[rolfk]

---

daliar@bynet-ts.co.il wrote:

Hi Dogu, 

I'm not a GPIB expert, but let me try to help you to find the solution. 

Honestly, I dont know what the Scan for instrument does behind the hoods, but you can see the GPIB functions (ib functions) by running the IO Trace (NI-SPY) at the same time you press the Scan for instruments. 

Debugging with NI IO Trace

This way, you can see what really happens when pressing the Scan for Instruments.

Basically, NI-VISA calls the low-level GPIP API. 

Let's leave NI MAX for a moment.

Which programming language are you using? CVI, C++, C#? 

Looking at your code, it looks is CVI or C. 

---

I think you misunderstood the OP. As far as I can see, he tries to implement a GPIB device on an STM32 embedded controller with a GPIO library. And on top of that GPIO library there is a macro definition layer that implements GPIB like operations using the GPIO library. When he then tries to scan for instruments using the HP IO library software suite it seems his instrument is properly found but when doing the same with the NI scan for instrument function in NI-MAX the device is not found. The code seems to be C, but some embedded programming for the STM32 target.

The GPIB bus protocol is fairly complex so it is quite likely that his GPIB implementation on the controller is somehow not quite right and that the HP software is somewhat less picky about that aspect.

I never worked on that level with GPIB but did support for GPIB customer applications at NI some 30 years ago, before IEEE-488.2 made it a very easy to use standard that was however only adapted by test & measurement manufacturers. All the others moved on to SCSI and then quite soon USB. But most of the nitty gritty details about GPIB I had no need to know for the last 25 years.

This problem seems so very much on a low level that I would guess that it is hard to find anyone who is willing and able to comment and even less give advice on this. Maybe on some hardware hacker forum but not likely here. People on this forum are at best GPIB users, not GPIB developers and in the last 10 years or so GPIB has become an outsider that is used less and less (but may still be used in 50 years by some for those old and very capable measurement devices that are still out there).

The scan for instruments option is not a big secret. As the OP already said it does indeed a FindAllListeners() operation which is a GPIB protocol sequence. It basically addresses all possible device addresses and checks if there is any device acknowledging the bus cycle. If so it considers that device present on the bus. This is already enough to present a list if GPIB addresses of valid devices. It then tries to query each of those devices with *IDN? and I think also with ID? as some older HP devices tended to answer to that, and then parses the response to use for a more descriptive VISA alias than just GPIB0::8. If the identification query fails it still will list the device under its generic name.

If I had a guess from the error message, it would seem that the device is actually not correctly decoding the MLA and MTA command and answering to multiple addresses instead of one specific one.