DQMH first step

[ben64]

I have a small project that seems perfect for a first use of the DQMH framework :  measuring torque value while a motor is accelerating.

Simplified overlook of the planned structure: I plan to have a command module that will send a start request to the motion module and to the acquisition module. I also have a data logger module that will save the data to a csv file. Acquisition rate is rather low 50-100Hz.

I want the csv to have the following format: date, time, actual_velocity, torque

What would be the best way to pass the data to the data logger module with minimum coupling? Using the timeout event of the command module to query both motion and acquisition module and then send a request to the data logger module with the received values? Is there a better way?

Thanks!

Ben64

[Gregory]

Hi Ben,

The Acquisition module can have a broadcast event that says "data has been acquired". I would fire this event when you have a couple seconds worth of data (10 sec = 1,000 data points seems reasonable) and when the acquisition has finished.

Your data logger will be subscribed to this broadcast event, but if it's not running, the data disappears into the ether, no problem 🙂

[ben64]

But how the torque will relate to the velocity in that case?

Ben

[Gregory]

I assumed the "acquisition" module was acquiring all of your data. If not, I would get rid of the "acquisition" module and make the acquisition occur in a helper loop of the motion control module.

[joerg.hampel]

Hey Ben, this sounds indeed like a perfect use case for DQMH. Before talking about the design of the application, I have questions about the acquisition part.

- How - and how often/fast - can you read the actual velocity? Is it read back from the hardware, or is it maybe an interpolation done in software?

- How are you planning to acquire the torque? Will you be using a DAQmx device?

The possible designs for synchronising the data will depend on which timing/trigger mechanisms you have available. 

[joerg.hampel · Accepted solution]

You can let both modules acquire their data in a helper loop each, and let those helper loops broadcast the data blocks (*) to the Command module. There, those data blocks can be merged and then sent via request to the Logger module. 

If both Motion and DAQ can acquire their data based on a precise (synchronised) trigger, you can make sure in the Command module that both sources sent a data block before processing those data blocks.

If Motion is much slower, or not triggered precisely, you could still let it broadcast velocity to the Command module, and then just take the most recent value when processing the data block coming from DAQ.

In terms of dependency, you could let Command module start Motion, DAQ and Logger. Motion and DAQ can send their data via broadcast. That way, only Command module is project specific, the other three modules remain generic and not statically linked to each other or to Command module.

(*) We usually go with a 1:10 ratio, sending a block of data 10 times per second. So when acquiring DAQ with 100Hz, we would send a block of 10 values every 100ms.

[ben64]

Thanks Gregory and Joerg for your help.

I don't have all the details yet but for the moment the instant velocity will be taken from the motion controller (NI-PCI-7332 or Advantech PCI-1245L) that's why it's in the Motion loop. The torque is read from a Futek IPM650 via usb. In the eventuality of a quadrature encoder for velocity the acquisition will be added to the acquisition module.

The synchronization doesn't have to be extremely precise, we are doing the characterization of a mechanical clutch in vacuum (torque vs speed/acceleration).

You just made me think that the motion loop is surely slower that what we can achieve with the acquisition loop. I think I will have the Motion and Acquisition module broadcast their data, in the command loop the torque data will be assigned to a variable and only when the Motion data is received (by the command loop) I will merge this data with the variable value (torque)  and send it via request to the logger loop.

Reading your post again (Joerg) I think this is pretty close to what you said!

Ben

[drjdpowell]

Just a suggestion unrelated to DQMH, but you might consider NOT combining your torque and velocity data into a single csv file.  Save all your data readings in either two files, or a more capable format single file (like TDMS, HDF5 or SQLite).  Do any resampling operation on this raw data in post processing.  This gives you full power to redo the resampling if you find, for example, that the torque readings are 6 ms behind the Velocity reads, or whatever.

If you do this, you could also consider an architecture that has no "logging" module, but instead has data-collection modules each write directly to file, with display/analysis modules reading in parallel from the file(s).