Anyone have experience with Mathscript RT?

[MarkCG]

I have a client who want to be able to use some of the control system code they developed in matlab/mathscript to do actual control with hardware. The loop rate will be in the 10-20 KHz range. Normally when I do RT development I would implement the control loop on FPGA for this sort of thing. I was thinking that perhaps the Mathscript RT module could be used to run matscript on a cRIO. The I/O would go through the FPGA interface node, not the scan engine as that is limited to about 1000Hz from what I understand.

I guess this boils down to two questions. 

1. Will the overhead associated with the matscript node for even the simplest script be high enough to utilize the entire CPU at a low rate like 1 kHz?

2. Can I/O be updated at 10-20 KHz through the FPGA I/O read write node?

Regards,

MarkCG

 

 

 

[smithd]

for (2):

cRIOs have a pretty wide range of performance, from 400 MHz power pc to 2 GHz x86. In any case, the results here should give you an idea of the maximum achievable performance: http://www.ni.com/white-paper/5423/en/

However I'm extremely surprised by these rates. The last I remember seeing indicated that PXI-class machines could hit maybe 40-50 kHz reliably (doing a useful task) and cRIO-class machines were limited to about 2-3 kHz. What I would expect is something more like the results at the end of this doc (http://www.ni.com/white-paper/14613/en/) which indicate the 9068 is at 50% usage at 1.7khz. The document implies that it can go much faster, and it probably can push its way to maybe 2.5 khz, but its a dual core processor so at some point you're going to hit the limit on one of the cores.

Scan engine is not limited to 1 kHz but I think the fastest I managed to get it on a 9068 was around 400-450 usec and even then it was flaky. Ethercat runs using scan engine and you can see the loop rates you can get here: http://www.ni.com/white-paper/52642/en/

Read write controls are like 1 usec (each) to execute, give or take some tens of nanoseconds, for a 32-bit value -- so technically yes its possible to hit your rates but I can't imagine how much they had to tweak and fiddle with (disabling interrupts, uninstalling non-essential software, optimizing code, etc.) to get the numbers in the first link. I've never heard of mere mortals going above 2k. 

 

tldr: I doubt you can hit those rates on any currently available compactrio target.

[MarkCG]

That's very good information, thank you! I kind of suspected this was a dead end. There seems to be a lot of potential for higher loop rates on the cRIO and this is an interesting thread related to this subject. 

http://forums.ni.com/t5/LabVIEW-Embedded/cRIO-Poor-Performance-Where-have-my-MIPS-gone/td-p/3026371
 

 

[smithd]

Ah yeah, I was actually thinking about that one one but its old and I forgot where it was. Its a good thread, if sad.

Edited August 31, 2016 by smithd

[TimA]

For question 1, 

Really it depends on what functions you're using. Something that appears simple (one or two lines in the MathScript Node) could have a lot of code behind it that needs to execute. I would definitely tread with caution and benchmark as much as you can.

And another message from the help that might be of interest and likely isn't too surprising:

http://zone.ni.com/reference/en-XX/help/371361F-01/lvtextmath/msfunc_classes/

Quote

Caution   (Real-Time Module) National Instruments does not guarantee and is not responsible for the jitter characteristics of the MathScript RT Module functions. Depending on the functions and data types you use, memory allocations might be required at run time, which can cause jitter in the real-time application. To ensure that the application meets timing requirements, National Instruments recommends that you benchmark (and you are solely responsible for testing) the jitter in your application before you deploy the application to the field.

[Neil Pate]

I would be pretty hesitant at trying to run mathscript nodes at anywhere near this rate. Not that I have tried to do it, just gut feeling tells me it would end badly.

Marc, that thread you linked to regarding cRIO performance is very interesting, pity there was no real answer from NI other than buy the new controller :-(

TimA I like your avatar :-)

[ShaunR]

Lots of caveats and manual optimisation (loop unrolling). Not all MS functions are suitable. Ability to meet RT deadlines you require is suspect. Risk analysis would probably yield "don't touch this with a barge pole".

If push came to shove then maybe some things might be possible with the node but the heavy lifting would probably need to be offloaded to meet spec. You would probably find the program that was written for the node isn't compartmentable to be able to offload defined chunks without complete refactoring of the script code.

[MarkCG]

15 hours ago, ShaunR said:

 Ability to meet RT deadlines you require is suspect. Risk analysis would probably yield "don't touch this with a barge pole".

 

16 hours ago, Neil Pate said:

I would be pretty hesitant at trying to run mathscript nodes at anywhere near this rate. Not that I have tried to do it, just gut feeling tells me it would end badly.

 

These are the conclusions I came to. MathScript RT seem to me like one of those typical NI products where they had a good thought but never REALLY followed through with it enough to make it REALLY useful. Possibly I'm just ignorant of people who rely on it and use it in their systems. 

There is a solution for running simulink and mathscript in real time out there it's just not part of the NI toolchain.

https://www.speedgoat.ch/

that's what I recommended the customer in question look at.

 

[MarkCG]

16 hours ago, Neil Pate said:

Marc, that thread you linked to regarding cRIO performance is very interesting, pity there was no real answer from NI other than buy the new controller :-(

Yes that kind of made me . I've learned to not expect a whole from the AEs who answer the forums or the phones, especially with performance questions. They are kids fresh out of college who have way less experience with LabVIEW than any of us and I don't think they are allowed to bother the engineers except for real emergencies. To their credit they do sometimes do a really good job diagnosing weird bugs and things like that so I am glad they are there for that.