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

PST.. Experimental event / trigger support for Pico SCPI labTool - 1: investigate

Jan Cumps
PST.. Experimental event / trigger support for Pico SCPI labTool - 1: investigate

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: initial investigations and preparing the project for custom registers.

image
image source:NI - fair use

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 

What does SCPI / LabVIEW need?

The first article I read is NI's Using Instrument Status Registers and Service Requests in LabVIEW. It explains the patterns that can be used to detect events on the PST. quote:

Watching and Responding to Events

Watching and responding to events is the catch-all for handling various instrument events whose condition is set in one of the event registers. All IEEE 488.2-compliant instruments can watch for and respond to standard events such as instrument error conditions. However, many instruments also have instrument-specific status registers with which you can respond to measurement-specific events. For example, when using a DMM, you might want to be notified when a voltage overload condition occurs. On an oscilloscope, you might want to be notified when a trigger event occurs.

For the PST, it will be useful if it can flag to LabVIEW if an input went high or low. This could be used in scenarios where a test setup has to wait for a user button press. Or if a sensor with logic level output is activated (proximity detector, optocoupler, …). The mechanism isn't real time, like a microcontroller interrupt event handler. But it's a settled SCPI pattern to detect and act on device events. LabVIEW has good handling for it.

What functionality is desired?

  • register that one (or more) digital inputs should listen to status changes
  • set a flag when such an event happens
  • ability to enable / disable / clear
  • support for more than 1 event?

Proof of successful implementation is when the firmware supports the register(s), and SCPI commands to deal with this.
The NI VISA Interactive Tester can be used to verify if these registers comply with the standards.
The experimental functionality will be ready for prime time when an example LabVIEW flow can perform those activities, using the standard blocks and patterns for this type of processing.

Prepare the SCPI parser configuration

You can follow along with this github issue, and see changes in this feature branch (will disappear once the development is merged with a project branch).

The SCPI parser has the mandatory IEEE 488.2 registers. It also allows instrument specific registers, if you change the parser's config.
The expected way to do that, is to create a file named scpi_user_config.h. The parser lib will include this file if you set the symbol PRIVATE SCPI_USER_CONFIG=1.
For Pico C SDK projects, you can set this define in the CMake file:

# enable use of scpi_user_config.h, to support custom device specific registers 
target_compile_definitions(pico_scpi_usbtmc_labtool PRIVATE SCPI_USER_CONFIG=1)

The parser lib will now include your custom definitions during the build. The first thing we tell the parser, is that we want to add instrument specific registers.

#ifndef _SCPI_USER_CONFIG_H
#define _SCPI_USER_CONFIG_H

#define USE_CUSTOM_REGISTERS 1

This will take care that the register API of the library gets to know our registers, and can talk to them.
If we don't define the complete set of needed registers, compilation will fail.
For the time being, I created an empty definition for all of these. It's a valid test to see if the user configuration mechanism works:

#define USER_REGISTERS
#define USER_REGISTER_GROUPS
#define USER_REGISTER_DETAILS
#define USER_REGISTER_GROUP_DETAILS
// TODO define custom status registers


#endif // _SCPI_USER_CONFIG_H

I tested this, and the end result is that the build works, and that the firmware works as before. It's ready to support the user registers, but there are none defined yet.
That is the point where I wanted to get at, for this initial investigation.

link to all posts

  • in reply to Jan Cumps

    Hi  

    That looks very reasonable! Slight smile Makes sense to me so far.

    There's always some minor variances in register design/naming depending on the instrument, but I think that sounds right for functionality. As long as one remembers which registers are which.

    I'll admit I'm not following your project too closely (I'm a bit busy as it is), but in terms of nice-to-haves, perhaps a couple of ideas:

    Wonder whether it might also be worth implementing a different custom register to hold number-of-events since last read (clears to zero on read, sort of similar how SYST:ERR? pops one error event off the stack on each read). This could potentially give you the ability to "count edges" on inputs guaranteeing that you won't miss any (and/or not needing to poll all the time).

    Alternatively, you could also make it even more powerful and make it gate-time-configurable so another set of registers acts like a frequency counter on the input (which might be useful for frequency inputs like optical tachometers).

    - Gough

  • in reply to Jan Cumps

     , this is how I designed it. Does it make sense?

    It is for digital IN functionality

    image

    DI-C condition: always contains the status of the digital pins. The firmware sets the bits (real-time-ish) based on their current logic level. RO
    DI-N and DI-P filter: enables propagation of positive, negative edge, both edges transitions to event register. R/W
    DI? event: latches when a transition happens in DI-C and filters above are met. RO

    DI-E enable: when set, propagates the "sum" of enabled bits to bit 0 of SCPI standard Operations register. R/W
    Bit 0 is the bit in the Operations register that I dedicate to holding Digital In status.

    If filters or enable are not set, all info stays in these custom registers. The status does not propagate to the standard SCPI registers.
    If set, the transition in a digital input pin propagates to SCPI Operations register.

    From then on it's standard.
    If I enable bit 0 in operation event, the bit propagates to Operations bit(7) of STB (status byte).
    If I set the Operations bit (7) in the Service Request Enable register, the SRQ mechanism triggers, and uses tmcusb dedicated channel to notify the host (LabVIEW / PyVisa).

  • in reply to ggabe

    I've been investigating further. I think that to enable the callback, I'll have to integrate/merge the SCPI lib's  ieee488 status register and the one from the TinyUSB driver.
    Then see if more is needed to make the usbtmc model SRQ aware...

  • in reply to ggabe

    I have to find out how I can let the lib make use of it. i found the callback that the lib invokes if a service request enabled event occurs. 

    because it doesn't implement (or assume a particular) communication layer, I'll have to do that most likely....

    edit: indeed. I need to find out how to write a callback that can safely invoke the TMCUSB callback
    Then register it in the .control hook:

    scpi_interface_t scpi_interface = {
    .error = NULL,            // haven't implemented an error logger
    .write = SCPI_Write,
    .control = NULL,        // haven't implemented communication channel control
    .flush = NULL,            // don't need flush for SCI / USB
    .reset = SCPI_Reset,
};

  • in reply to Jan Cumps

    (can't edit.) This part should say:

    Set that OPERATIONS bit in status byte is enabled for event generation:
    *SRE #H80