Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 1649 views
  • Likes 7 likes
  • Comments 14 comments
Related
Recommended

PST.. Experimental event / trigger support for Pico SCPI labTool - 6: Service Request from Instrument to LabVIEW flow

Jan Cumps
PST.. Experimental event / trigger support for Pico SCPI labTool - 6: Service Request from Instrument to LabVIEW flow

The Pico SCPI labTool (PST) allows you to connect your PC to equipment to control and monitor all sorts of things. It runs on a Raspberry Pico. It would be nice if the PST could supports device dependent SCPI registers. They can be used to notify a LabVIEW flow from the device. We finally managed to notify LabVIEW when a GPIO input changed logic level.
In this post: I continue to test the USBTMC Service Request Event generation. And the handling in PyVISA and NI's interactive test tool.

image

The current TinyUSB library doesn't make it easy to add this type of functionality in a neat way.
Thank you  for picking this up and for adding the Service Request handling and test script.

part 1: PST.. Experimental event / trigger support for Pico SCPI labTool - 1: investigate 
part 2: PST.. Experimental event / trigger support for Pico SCPI labTool - 2: design the registers 
part 3: PST.. Experimental event / trigger support for Pico SCPI labTool - 3: Instrument Specific Registers Test
part 4: PST.. Experimental event / trigger support for Pico SCPI labTool - 4: let TinyUSB USBTMC code use SCPI-LIB's Status Byte register 
part 5:  PST.. Experimental event / trigger support for Pico SCPI labTool - 5: Propagation to IEEE488.2 SCPI Registers Test 
part 6: PST.. Experimental event / trigger support for Pico SCPI labTool - 6: Service Request from Instrument to LabVIEW flow 
part 7: PST.. Experimental event / trigger support for Pico SCPI labTool - 7: Test Service Request from Instrument to LabVIEW flow 

Test Setup

Again, I continue from the previous post:  PST.. Experimental event / trigger support for Pico SCPI labTool - 5: Propagation to IEEE488.2 SCPI Registers Test 

We managed to fan a negative transition on Digital In PIN 2 (a button connected to GPI27), to the standard Operation Status register. And to stream the notifications upstream up to STB and SRE. Now we test that the USBTMC protocol pushes the notification from the Pico to the PC software.

image

Tests will systematically validate

  • (tested in post 5) can I propagate an event from the Operation Status register to the Status Byte register?
  • (tested in post 5) did I land in the SCPI-LIB and USBTMC Service Request invocation code?
  • can I set up a SRQ handler and let it run when expected (button press)

Test SRQ with NI VISA Interactive Control

Let's first bring the device in the condition that button presses fan out to OPERATION STATUS EVENT register, and propagate all up.

STATus:OPERation:DIGItal:INPut:NTRansition 4\n
STATus:OPERation:DIGItal:INPut:ENABle 4\n
*CLS\n
STATus:OPERation:ENABle 1\n

Enable propagation by setting SRE Bit 7 (OPER Bit) to 1

*SRE 128\n

test 1: Register the Event Handler and prime. Request should time out because we don't generate the event that it's waiting for.

condition:

  1. Enable Service Request Event handling
    image.
  2. Wait on the event with a 2 second timeout. Don't push the button. This should generate a timeout.

  3. Wait on the event with a 2 second timeout. Push the button within those 2 seconds to generate the event.

result:

Result when button is not pushed while we wait for the event:
image

Result when button is pressed within the timeout:
image

pass

Test SRQ with PyVISA

Here, the code sets up the right condition, and will loop until the button is pressed

test 1: validate that the code loops until button is pressed

def handle_event(resource, event, user_handle):
	print(f"Handled event {event.event_type} on {resource}")
	stb = inst.read_stb()
	inst.write("*CLS")


rm = visa.ResourceManager()
reslist = rm.list_resources("USB?::?*::INSTR")
print(reslist)

if (len(reslist) == 0):
	sys.exit()

i = 0
inst = None
while i < len(reslist):
	inst = rm.open_resource(reslist[i]);
	inst.timeout = 3000
	inst.clear()

	print("Experimental test")
	inst.called = False
	event_type = constants.EventType.service_request
	event_mech = constants.EventMechanism.handler
	wrapped = inst.wrap_handler(handle_event)
	user_handle = inst.install_handler(event_type, wrapped, 42)
	inst.enable_event(event_type, event_mech, None)
	
	inst.write("STAT:OPER:DIGI:INP:NTR 4\n")
	inst.write("STAT:OPER:DIGI:INP:ENAB 4\n")
	inst.write("STAT:OPER:ENAB 1\n")

	inst.write("*CLS")
	inst.write("*SRE 128") #leaving Bit6 MSS - off
	
	print('Done setting up. Drive DIGI:INP0 low (push button connected to GP27)')
	   
	
	try:
		while not inst.called:
			time.sleep(0.01)				
	except: 
		inst.close()
#	   logging.exception("While looping")

	try:
		inst.disable_event(event_type, event_mech)
	except:
		print('err while disabling event')
	try:
		inst.uninstall_handler(event_type, wrapped, user_handle)
	except:
		print('err while disabling event')
	
	inst.close()
	i += 1

print("All Test complete")

result:

Experimental test
Done setting up. Drive DIGI:INP0 low (push button connected to GP27)
Handled event 1073684491 on USBInstrument at USB0::0xCAFE::0x4000::E6614104036A9438::0::INSTR

pass

link to all posts

  • in reply to shabaz

      , if we keep calibration in the Pico flash, we'd automagically inherit a backup and restore tool for it:

    "Load allows you to write data from a file into flash
    Save allows you to save a range of memory or a program or the whole of flash from the device to a BIN file or a UF2 file"

    It could either backup firmware with calibration section,
    or when the right addresses used, only the persistent storage area.

  • in reply to Jan Cumps

    I definitely agree, there should be a demarcation. It could be that perhaps only RAW read/write should be implemented for basic I/O, because then anyone who attaches specific hardware (for instance, a sensor of some sort, or a voltage measurement or whatever), can add their own MEAS:TEMP or MEAS:HUMidity or MEAS:VOLTage and so one, hard-coded if they want, to whatever their hardware supports. Or a skeleton single MEAS:<PARAMNAME> that a user modifies, but it increases effort to maintain all these things, I think it's better for a user to implement on their custom project, and if they feel it is generic enough, then they could request pushing their changes into the current feature branch at that time, with no guarantee that it will be accepted.

    I don't know if it makes sense to have a RAW EEPROM capability or not, I think it could be worthwhile, because even on a standalone instrument, there is likely to be an analog input or output board of some sort, and may well need cal coefficients, but I think that the specifics (calibration coefficient format and so on) doesn't need to be in the base project. The suggestion of just a single EEPROM (i.e. no card stuff) makes sense. It could also be argued that even a EEPROM is not needed, since there is Flash, but EEPROM would allow to tie the coefficients  to the hardware that they are using (e.g. if they wish to swap out the analog board during testing, they don't need to keep track of the separate board coefficients. On the other hand, as you say the Pico is cheap, so they could just swap out both the Pico and the analog board (or have them both on the same board).

    If an EEPROM is worthwhile then DEV:MEM:BYTE seems like a good idea, it's enough for a user to either prototype using that and performing any byte manipulation in the external application (i.e. with LabView, or Python and so on) or they can code their own specific formats into their project rather than the base project.

    I guess it's easy to decide at any point if a feature should be included or not, since whoever creates a feature will have it in their fork, and it's not automatic to get a feature accepted into the feature branch, so they could just run with their fork without having to redo anything.

  • in reply to shabaz

    ( different possible approach):

    A Pico is cheap.
    The PST could be(come) a template project, only supporting USBTMC and SCPI functionality (and maybe basic IO/ADC with built-in peripherals)

    Any project that wants additional functionality, can use the base project and add what's needed to make that instrument work (hardware, code, additional SCPI commands).

    It would keep the overall code (both of this project and the specific one) simpler.
    And possibly also removes the task to recognise and be able to talk to a set of plug-ins.

    thoughts?

  • in reply to shabaz

    SCPI read/write in raw hex, useful for debug purposes

      , let's use DEVElop: for that

    example:

    read: DEVElop:MEMory:BYTE? (with address as parameter, e.g. DEVE:MEM:BYTE? #H10)

    write: DEVElop:MEMory:BYTE (with address and value as parameter, e.g.: DEVE:MEM:BYTE #H10, #H1F)

    I did not provide a location for the card indicator. Have to read up more how devices deal with that syntax subset. My DMM6500 supports it, so I can try out how it works. 
    It's not straightforward. Suggestion: let's try to make it work for 1 EEPROM, or for the one on board of the Pico ...