REINIT_DAQ

[mortenfc]

Hi!

I get a sequence error during alloc_odt of my 2nd daq list. In the standard it says to REINIT_DAQ

I can see in the source code this error action is not implemented

How do I reinit daq? I can't find any information about it anywhere

[christoph2]

The only thing that comes to mind, would be FREE_DAQ, but this usually (like in my own Blueparrot XCP project) resets/restarts an internal state-machine, so one has to run FREE_DAQ - ALLOC_DAQ again. ERR_SEQUENCE on ALLOC_ODT almost always means that this initialization sequence is missing. Because nobody knows how many DAQ lists the user wants to allocate if ALLOC_DAQ is missing, the only reasonable action is program termination -- OK, I should add an explanatory message. Your first ALLOC_ODT works? Really strange...

[mortenfc]

I was doing

FREE_DAQ ALLOC_DAQ(2) ALLOC_ODT ALLOC_ODT_ENTRY ALLOC_ODT -> Sequence error

I just saw in the standard you have to call all ALLOC_ODT before ALLOC_ODT_ENTRY :D

[christoph2]

Yes, to put it into another words: There's no way back to higher level functions.

s. Blueparrot state-machine: https://github.com/christoph2/cxcp/blob/master/src/xcp_daq.c#114

[mortenfc]

This may be out of topic, but what command PID do I use to send a STIM package to a STIM daq list? There is no command for CommandCategory.STIM

I am trying to do SOFTWARE IN THE LOOP from the standard documentation, but missing description for how to send a STIM DTO

[christoph2]

STIM functionality isn't implemented yet; due to strict timing requirements in most cases, a C++ extension is needed. Any ideas how a STIM API could look like, are highly welcome!

[mortenfc]

Creating a user-friendly and flexible API is probably tricky, since there are many ways to do stimulation, and different setups for different hardware. But one could maybe start with

createStimDaqLists(dict_of_measurement_var_sizes_and_addresses, dict_of_stimulation_var_sizes_and_addresses) -> stim_daq_number = 0, meas_daq_number = 1, free_daq -> alloc_daq(2) -> alloc_odt (assuming less than 255 variables) -> alloc_odt -> alloc_odt_entry -> alloc_odt_entry -> for each stim variable: {set_daq_ptr(0, 0, i) -> write_daq(0xFF, var_byte_size, 0x00, var_address)} -> for each means variable: {set_daq_ptr(1, 0, i) -> write_daq(0xFF, var_byte_size, 0x00, var_address)} -> set_daq_list_mode(mode=0b00000010) (stim) -> set_daq_list_mode(mode=0b00000000) (meas)

beginStim -> start_stop_synch(mode=0b01)

sendStimDto -> fill header and identification field based on configuration in get_daq_processor_info and the standard, then add payload data of stimulation variables concatenated (this doesn't seem to work for me, I'm not sure what I'm doing wrong)

receiveDaqDto(slave_cycle_period) -> pop_dto_queue with 1 cycle slave timeout, and parse based on types and order configured in createStimDaqList (this works for me with multiple variables, although for performance reasons it only sends a packet around every 2 cycles of the slave (20 ms instead of slave period of 10ms) )

[christoph2]

OK, looks like a good starting point.

Regarding timing, I'll start a separate GH project, including a MIDI arpeggiator!? There's really a close technical relation between DAQ/STIM and MIDI applications when it comes to timing:

• It makes no difference if a DAQ list is send every 20ms or a drum-machine runs @125BPM, but don't expect to measure exactly 20ms on a non-RTOS... The challenge is now to extract the exact period value -- α/β- or even Kalman-filtering, we'll see...
• Playing notes of a chord over and over again at exact points in time corresponds roughly to STIM.