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

PST.. Experimental event / trigger support for Pico SCPI labTool - 5: Propagation to IEEE488.2 SCPI Registers Test

Jan Cumps
PST.. Experimental event / trigger support for Pico SCPI labTool - 5: Propagation to IEEE488.2 SCPI Registers Test

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. I'd be happy if we can notify LabVIEW when a GPIO input changed logic level.
In this post: I continue to test the registers fanout up to the USBTMC Service Request Event generation.

image

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

I continue from post 3  PST.. Experimental event / trigger support for Pico SCPI labTool - 3: Instrument Specific 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. Let's now test the upstream up to STB and SRE

image

Tests will systematically test

  • can I propagate an event from the Operation Status register to the Status Byte register?
  • did I land in the SCPI-LIB and USBTMC Service Request invocation code?

Test IEEE488.2 Standard Registers

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

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

Do this before each of the test cases. This will take care that the next button push will propagate to that bit.

test 1: OPERATION STATUS ENABLE and STB registers

condition:

  1. When OPERATION STATUS EVENT register Bit 0 is set (see part 3 on how to do that), STB OPS bit (Bit 7) should not be set (we have not enabled it)
  2. Set OPERATION STATUS ENABLE register bit 0 to 1. Query it back.
  3. STB OPS bit (Bit 7) should still be 0,  because we did not generate an OPERATION STATUS event
  4. Push the button to make OPERATION STATUS EVENT Bit 0 go to 1. STB Pin 7 should now be 1

result;

1:Query STB by pressing the VI VISA tool's Read Status Byte button (this does not clear bits)

0

2: Enable the fan-out, and check back

STATus:OPERation:ENABle 1
STATus:OPERation:ENABle?
1

3: Query STB by pressing the VI VISA tool's Read Status Byte button (this does not clear bits)

0

4: Push the button. Push the button STB Bit 7 should be 1

128

pass

test 2: SERVICE REQUEST ENABLE register (and do we land in the Service Request code?)

condition:

  1. Start the firmware in a debugger. Set a breakpoint in first line of SCPI lib source file ieee488.c, function writeControl(). Run the test case initialisation commands.
    Enable the Operation Status propagation too.
    Debugger should not break yet.
  2. Set SERVICE REQUEST ENABLE register OPER Bit 7 to 1. Query it back.
    Push the button to make OPERATION STATUS EVENT Bit 0 go to 1. The debugger should break

result;

1: I use VSCode. Started the firmware in debug mode with the breakpoint set. Executed the 3 initialisation SCPI commands

STATus:OPERation:DIGItal:INPut:NTRansition 4
STATus:OPERation:DIGItal:INPut:ENABle 4
*CLS
STATus:OPERation:ENABle 1
debugger doesn't break

2: Enable propagation by setting SRE Bit 7 (OPER Bit) to 1, and control if it is set

*SRE 128
*SRE?
128
#push
code breaks :)

image

pass

link to all posts

Parents Comment
  • in reply to Jan Cumps

    Got an SRQ event fired in PyVisa! Faked a response of an incoming status request to match the bTag of an async SRQ. Did it by setting the tag to 0x01 as in Table 6 of the USB488 specs, and voila, NI IO Trace and PyVisa both identified it as an SRQ!

    image

    image

    The read status byte request timed out, however it's encouraging to see PyVisa got it!

Children
  • in reply to ggabe

    When I implemented the registers, I used up all my free brain capacity Slight smile.

    Now that's finished, can spend time trying to fully understand the communication.

    > The read status byte request timed out

    I need to check that. It seems to work with the NI VISA Interactive Control application...

    There is more to check. I think that the application currently not always removes the MAV flag. Maybe I can run the original TinyUSB example and see if it's my code or the example framework...

    edit: I think it's a library manco:

    // TODO:
// ...
// Clear message available status byte at the correct time? (488 4.3.1.3)

  • in reply to ggabe

    > The read status byte request timed out, however it's encouraging to see PyVisa got it!

    Without changing code, the ReadSTB doesn't time out for me

    image