Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 1805 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

Parents

  • Also great to see people contributing to the project!

    Hope this isn't hijacking the post too much (I can create a new thread to discuss this if needed    )

    Three new feature proposals (I'm not sure I can work on all these, but still it's interesting to maybe add them to the backlog if people think they are useful). Actually one is an enhancement, the other two are new features:

    1) The analog input HIRES module enhanced to also support differential inputs and configurable gain
    Example differential, gain of 4:


    CONfigure:ANA:HIRES DIFFerential,4


    Example single-ended, gain of 2:


    CONfigure:ANA:HIRES SINGle,2

    2) A new Board Memory (BM) module to suport cheap EEPROM on add-on cards for identification or for calibration parameters
    First release to only support SCPI read/write in raw hex, useful for debug purposes

    Example, write to card #0 (there could be several EEPROMs on the I2C bus, they can all be referenced by a card number which gets added to the base address which is 0x50 for most I2C EEPROMs, plus the card value which relates to the address pins on the EEPROM chip), 4 bytes 0xaa, 0xbb, 0xcc, 0xdd from address 16:


    CONfigure:BM:RAW 0,16,aabbccdd

    Read 4 bytes from card #0, from address 16:


    FETch:BM:CARD0:ADDR16:4:RAW?

    3) A new system temperature module to support the measurement of either ambient temperature of the system, or board temperature of individual cards. Card 0 would be ambient temperature.

    Example to read the temperature of card #2 (this is assuming cards begin at #1, if zero will be ambient temperature):


    TEMPerature:CARD2?

    I'm not very good at thinking what the syntax should look like, the above is an attempt to keep some flexibility, but at the same time not making things too complicated or too large a bite for a first release of such functionality. But I suspect I've got things horribly wrong and broken conventions I bet, so I'm not too loyal to my own suggestions, I'd rather take as much advice as possible. Also tagging  in case he has some advice based on his experience with similar intent type of commands perhaps.

    Any suggestions welcome!

  • 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 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.

Comment
  • 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.

Children
No Data