Any concerns using DCAF for production tester control system

[ryan_sheppard]

Interested if any one has experience using DCAF framework for a control system on a production tester? This is our first production tester software that we will have developed, and I know TestStand is the suite that covers this type of application. But the goal is to have a LabVIEW only solution (external constraints). 

Hardware wise we have quite a few cDAQs laying around, so we use those with the DAQmx module. The application will be controlling quite a few valves, reading from a flow meter, reading pressure transmitters, etc. For data logging I am thinking we would run with the TDMS module to start, but possibly run another application parallel if we need higher sampling rates. But any data logging is better than pen and paper. For the logic side of things we'll have to develop a custom static module, but that's not too much of a concern. I am thinking a custom static module for each of our tests, that are loaded based on the config file. I'll need to implement some type of UI, displaying readings and user input. One of my concerns is automated control and manual control, and allowing a user to control valves if need be when not performing a standard test. But I guess that could be another configuration file that allows for more manual control (not sure if I like that idea).

We're not looking for a fully automated test sequence at this point. I could see that being an issue down the road if we plan to deploy to a production setting though.

Before my experience with DCAF recently, we have quite a few DQMH modules developed and we're planning on creating a DQMH based application. But because of all the controls, I think DCAF would be a better fit. And if we need too, we can develop a DQMH based app to run parallel to the DCAF app.

From my basic experience I can see DCAF being a good fit, but I am confirming I am not trying to fit a square peg in a circle hole.

[Jacobson-ni]

For the manual vs. automated control of certain outputs, you should look into the tag select module.

[Robert_Hoffman]

Ryan,

We have spent some time evaluating and benchmarking DCAF against our own embedded framework (STAX) for production test applications (there is a previous post on this comparison that I did at NIWeek 2018).  In general, we found them to be pretty similar performance and functionality, but DCAF is missing some key things for production testing that you will have to create on your own.  You brought up datalogging, and DCAF is not really designed for high speed acquisition and analysis.  Also, DCAF is missing a logic engine, which you may not need at this point if you are not automating a test.  The single threaded nature of DCAF is something that you will have to be careful with also, especially if you have a lot of communications or other non-deterministic aspects of the program that have to be asynchronous.

I would be happy to chat with you further about the application - we specialize in production test systems, and I could probably help point you in the right direction.  I published a case study on our platform recently - https://www.controldesign.com/articles/2018/when-a-plc-isnt-enough/.  

Thanks,

Rob

[NickNZ]

Hi

I wanted to avoid Teststand for a production tester and started off with a QMH framework (To program the UUT) and then I hoped to hook into the acceptance testing framework that the software guys were already using. Turned out that the acceptance testing framework was no good with logic/branching (e.g. "If PCBA skip this test") and I had already pushed the QMH handler to its point of un-maintainability just in setup of the UUT and getting it programmed.

Square peg round hole - the acceptance testing framework was designed for acceptance testing and not for production test and it would be to much of a compromise to drag it to production testing - despite the advantage of keeping the production test software maintained by the product software team.

So bit the bullet and went to Teststand as we already had a licence so I just brought a 5 pack deployment licence. 

In the end had almost 1000 steps in the end for testing a PCBA, Box assembly and final configuration. This number is considerably more >5x than the number of messages I initially thought I would need!  The good thing was that I was able to easily port most of my functionality from the QMH to Teststand. So down the track if you have to automate how much work can you salvage? 

How many SKUs of the product are your likely to have? More SKUs means more exceptions, logic and different parameters required. 

So while you don't elaborate on your resistance to Teststand, it sounds like you have a complicated fixture to support test. 

Perhaps a hybrid solution of DCAF for maintaining the functionality of the fixture and then use the E2E or UDP module to run another DCAF host on a remote Test PC. Use can use CVT to pass tags on the PC end that are interfaced with a QMH to provide your sequencing / logic. 

This setup would look like:

Test PC running a DCAF host and a QMH.

UPD or E2E module swapping tags with a CVT module you can access from your QMH.

cRIOs on Fixtures - read and send data back to test PC via UDP/E2E. Do all the control of the fixture setup. (Assumes cRIO has processing capability for its own host) or else you program up the FPGA on them and use the FPGA module to get data back to the Test PC. 

Once you outgrow the QMH you can swap over to TestStand. 

[ryan_sheppard]

---

@Robert_Hoffman wrote:

Ryan,

We have spent some time evaluating and benchmarking DCAF against our own embedded framework (STAX) for production test applications (there is a previous post on this comparison that I did at NIWeek 2018).  In general, we found them to be pretty similar performance and functionality, but DCAF is missing some key things for production testing that you will have to create on your own.  You brought up datalogging, and DCAF is not really designed for high speed acquisition and analysis.  Also, DCAF is missing a logic engine, which you may not need at this point if you are not automating a test.  The single threaded nature of DCAF is something that you will have to be careful with also, especially if you have a lot of communications or other non-deterministic aspects of the program that have to be asynchronous.

I would be happy to chat with you further about the application - we specialize in production test systems, and I could probably help point you in the right direction.  I published a case study on our platform recently - https://www.controldesign.com/articles/2018/when-a-plc-isnt-enough/.  

Thanks,

Rob

---

Rob, 

Thanks for the reply. Luckily for our UUT, high speed data acquisition is not necessary so I am not too concerned about that. I figure at this point the logic engine will be the only development that will need to be completed before we could get up and running.

I would be open for a chat on the application, it would much appreciated. 

[Robert_Hoffman]

Ryan, feel free to email me at hoffman@signalxtech.com and we can chat further.

Also, there is probably a point of clarification here on the single-threaded comment.  It is true that the engine is single threaded, but it is easy to make a module run asynchronously, which allows for parallel execution of processes that may be non-deterministic.  However, I think it is important to understand the implications of this change on how your overall application will run.  It is easy to do, but it can have big ramifications on the control system that should be well understood before you make those changes.

Thanks,

Rob