Simulating or Custom DAQmx task data

[MNevels]

I've got a fairly mature application that relies heavily on DAQmx tasks created in NI MAX to read in continuous analog data. We do all the scaling and channel configuration in the MAX task and so can tailor the data acquisition for each application using many different configurations of analog input hardware, channel counts and ranges without modifying the program itself for each hardware implementation.  

We will soon have a need to acquire signals from multiple devices using RS485 rather than analog input.  I would very much like to continue to use my program without having to rewrite the acquisition and memory buffers deal with this as it's all setup to use continuously acquired tasks that are configured in NI MAX.  

I often use DAQmx tasks with simulated channels during testing and that is a very useful tool.  Considering that this simulated data is generated in software, I'd like to think there's a way to create my own simulated data for a simulated module in a task created in MAX. This way I could use one application to poll the RS485 devices and update the simulated data stream with the current value, then the main application would read it just the same is it would if it were continuously sampled analog data. I recognize that there are issues with regard to the differences in timing of the serial data and simulated sampled analog data, we do not have any issue with the jitter that would be introduced in that process. Or, alternatively, is there any other way to inject my own data into a MAX task?

[Kevin_Price · Accepted solution]

Short answer: no.

Time for some code work...

-Kevin P

[cbutcher]

If the existing application is really, really difficult to change, and introduce e.g. a Hardware Abstraction Layer, then I suppose you could (with a second (or the existing?) DAQmx device) create a second application to acquire the data over RS485, then output it to something you could wire to your existing hardware?

This most definitely isn't my recommendation! I'd suggest the HAL for sure, it would also allow you to create simulated data in the way you wanted (e.g. for testing, simulation, reproducing situations, whatever) in addition to the intended use of allowing the addition of an RS485 data source/collection of sources.

[Kevin_Price]

I think I like cbutcher's clever variation on your idea (having a separate program turn the RS485 stream into actual analog signals for your original program) more than he seemed to.  But I do agree that it's kind of a last resort approach.

Reading your post again, it seems that the RS485 communication itself isn't your pain point.  Rather, it's the particular detail that you're been relying on MAX for your task config and data scaling, and this approach doesn't extend to communications connections.

Though you could use MAX to assign a logical alias for a VISA resource, you won't be able to change things related to parsing, interpreting, or scaling the data you get from a device.   You might need to use a config file and then you may want to make a little configurator utility for your user(s).  That'll be better than needing to edit a config file directly.

-Kevin P

[MNevels]

Thanks Kevin_Price and cbutcher for your input.  cbutcher's variation is one that I've considered and, depending on how this project scales, is not necessarily out of the picture.  Kevin_Price, you are correct - the flexibility of MAX configuration of tasks and data scaling is the key feature has allowed this program to work for so many of our projects for so long and why I was looking for a way to integrate serial data into a MAX task. 

I've looked through all the documentation I could find and, finding nothing, thought it best to ask on the forums to see if there's any option that I wasn't seeing to be able to inject my own data into a MAX task.  I wasn't expecting to find it but you never know when someone might have a clever trick.  I'm sure it is 'technically possible' but it's just something that we haven't been given the API hooks to implement.  I do acknowledge that this is outside the scope of what MAX tasks were intended to do and so this was a long shot. 

I will  go back to the source of our current application and dig into how much refactoring it would take to insert a more abstract HAL that would allow for the selection of any number of modules that could be implemented to acquire from various data sources.  This program has had many features added over the years and, while at it's core it is somewhat flexible, I believe it has outgrown it's architecture.  Depending on how interconnected the DAQ and Data models look it could be a net time and cost savings to implement a RS485 to Analog solution rather than a major refactor if that's what it turns out to be.

Thanks again for your feedback - it's at least good to get confirmation that what you suspected is actually true.

[cbutcher · Accepted solution]

I realise you didn't ask this, and that you may already know, but if you're not super worried about future extensibility, but do want to try the HAL approach, you can probably get a decent fraction of the way by just wrapping all of your DAQmx calls in class methods (in some cases, literally just the DAQmx VI) and then coercing the new implementation to behave like DAQmx.

Some methods will be fairly straightforward for this (e.g. Read) and some less straightforward (various configuration VIs, especially if you're trying to use MAX stored configurations as your input - but if you try getting the simplest data types you can and optionally "translating" enums you can probably do ok).

Edit: Here's an example for getting some values out of a MAX configuration. It's a) a bit fiddly, and b) perhaps not something you want to do, but hopefully at least useful to know about:

You can see here also that the Min and Max values return the coerced range, not what you necessarily have in the config, but as far as I know (and Kevin can hopefully correct me if I'm wrong) devices basically have preset ranges (available in their specifications) and so here it widened to the narrowest supported range that fit my input requirements. Not sure if that will be relevant to an RS485 data source configuration though...

[MNevels]

That's an excellent suggestion!  I currently launch the compiled executable with the desired MAX task as a command line argument. This allows me to setup shortcuts to run multiple instances on a few machines that each are connected to multiple cDAQs with different analog input modules. The command line arguments make this super flexible because I never know what kind of setup may be used, if I can set it up in MAX the application will get everything it needs (range, units, timing, channel count, etc.) from the task's property nodes.   I could easily modify the command line argument handling so I can select the data acquisition implementation and the correct child class would be selected and used.  Creating a parent class that replaces my current DAQmx calls would allow me to use a child class to directly implement exactly what the program is doing now and then I could implement a new child that could launch a dqmh module that managed all the RS485 communication and buffer the data until a read is called.  The new read implementation could take the timestamped RS485 data and generate equivalent waveform data that would be returned exactly as if DAQmx had read analog channels from a MAX task. 

Or maybe better yet, I could write a separate application for dealing with the RS485 communication that has all the other features that I need to use to work with these products (reading/writing configuration values, calibration, programming serial numbers) and have that application setup a network stream for the data. Then the new child class in the current application could open that stream and bring that data in, easily allowing us to use the same toolset for burn in and data management that everyone is already familiar with. 

For the purposes of this application I think this sounds like the quickest way to implement what I'm looking for.  It may not be the full HAL that might have been designed if these data sources were requirements when this program was architected but I can get exactly the functionality I need from this approach and It wouldn't take much to add new functionality if needed in the future.  

Thanks again - great idea!