MarkCG

I am really just writing this to put thoughts to paper so it is a meandering post with no real point. In past projects I used a layer of indirection between scan engine and fpga I/O by means of the current variable table, with all I/O scanned and written to the table in one place in the code. This made it easy to substitute value in the CVT with simulated values inputted from a test panel.

I abandoned that approach in subsequent projects because it seemed not quite right. You have shared variables, why was I bypassing that entire system, which has a lot of functionality and add ons, for some parallel system ?

For projects where I just use the cRIO scan engine, I want to cook up a system where my test panel programmatically takes control of all the cRIOs's I/O via this "force variable" functionality. I'd like to run my the real time program on an cRIO chassis devoid of modules so I can see how the program performs on the actual hardware while testing out logic and functionality thorough manual test panels as well as unit tests.

Anyone one else do it this way or try it before?

48 minutes ago, rolfk said:

Definitely! NI licensed the Xilinx toolchain from Xilinx to be distributed as part of the FPGA toolkit and there will be certainly some limitations in the fine print that Xilinx requires NI to follow as part of that license deal. They do not want ANY customer to be able to rip out the toolchain from a LabVIEW FPGA installation to program ANY Xilinx FPGA hardware with and not having to buy the toolchain from Xilinx instead, which starts at $2995 for a node locked Vivado Design HL license, which I would assume to be similar to what NI bundles, except that NI also bundles the older version for use with older cRIO systems. So while NI certainly won't like such hardware offerings, as it hurts their cRIO sales to some extend, they may contractually be obligated to proceed on such attempts to circumvent the Xilinx/NI license deal, if they want to or not. 

I like many others have wanted to be able to target any Xilinx FPGA with LabVIEW. There are at least two projects that I could have done if this was possible. What these guys have done is impressive. I hope product forces NI and Xilinx to finally officially allow targeting any and all Xilinx FPGAs with NI tools. They could try taking legal action but I think they have more to lose than to gain by that route.

Who would certify it in any meaningful legal sense? If instead they mean someone, employee or consultant, looks over it and says on paper "I don't see any obvious malicious code in here" that might be feasible, you could open each of the VIs in the packages you will use and inspect each one. I think the license for LabVIEW itself has some kind of verbiage in it that it's all "at your own risk" anyways. That sound like a pretty onerous requirement. 

On 10/4/2016 at 0:40 PM, viSci said:

I was dismayed when a large client announced they are abandoning their sizable investment in NI cDAQ HW to go with the Siemens LMS SCADAS system.   It got me wondering why NI does not offer something to compete with this type of Uber DAS system and software.  Certainly NI has the HW covered, although LMS has a better take on DAS HW with multi-functional inputs (voltage, current, PWM, etc).  I would love to hear your take on the subject... Just a side note that the systems I am talking about are fairly small < 32 channels, so it is not the large network based scalability of the LMS that is the selling point.  Rather it seems to be the desire to have full featured, fully integrated, off the shelf software supported by a larger company that is the draw.

I would bet that part of it is they see not hiring consultants to set up and write software for the system as a plus as well.

I remember seeing Elijah's presentation at some event or another and I thought it was pretty slick. I spent a good amount of time following the actor framework discussions on the NI community group but decided I really didn't need the functionality that was on display there for almost anything I did. I do use HAL but not based on Actor Framework.

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.

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.

A very good way to take an N-order derivative of a noisy signal is the Savitski-Golay filter, which is in LabVIEW. Read up on it, you will see it is much better than the naive method of taking the derivative (the simple forward, backward, and central approximations)

A technique called "cepstral" analysis is often used to find echoes. I don't think LabVIEW has a cepstrum VI that comes with the standard analysis library but MATLAB does

http://www.mathworks.com/help/signal/ref/cceps.html#bub3q8y

There is cepstral analysis in the adavanced signal processing toolkit

http://www.ni.com/example/30654/en/

18 hours ago, smithd said:

Its nice to see him decide to move on. It'll be interesting to see if the company changes with Davern in charge (esp since he is the CFO/OO with a business and accounting background).

yeah really hoping he won't drive the company into ground. You always hear horror stories about CEOs strip mining the company to boost stock prices in short term and get a nice bonus.

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
 

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

LabVIEW is not recompiling my RT MAIN.vis  every time I open one of these projects. I do not have source separated from code either. I wonder if it has to do with VIs shared by both RT and Windows.

Yes you can write a program in LabVIEW to communicate to the instrument. Writing instrument drivers is tedious but you have all the tools at your disposal to do so via LabVIEW. The USB port is 99% probability a serial port emulator. When you plug the instrument into your computer it should show up a "COM port" . You the write and read strings to this port with the VIs that under the VISA pallet under instrument control. You have to make sure all your baud rate, parity, and other serial settign are correct and match the specification of the instruments . The company will have some sort of document that lists these commands so get your hands on that and look at the some of the serial comm examples and start using that example VI to write commands to the instrument.

That's great! The couple of times I went to NI week I felt like the NI presented sessions were technically extremely weak. I really like the conference fee and lost work time was not worth it for this reason. It may convince me to come next year.

On 6/23/2016 at 7:57 AM, smarlow said:

33% of a potential market sounds great, until you realize it is one out of three, and the salient customer descriptor is "Big".  Charging higher and higher prices to fewer and fewer deep-pocketed customers is not a long-term strategy for survival.

You really hit the nail on the head here smarlow!! I wish NI would GET THIS.

On 6/20/2016 at 2:31 PM, ShaunR said:

The usual issue is finding out the processor you chose based on cost, isn't enough to run ethercat and your application at the same time (half way through your project ). If you are not using the FPGA then I highly recommend spending the extra effort and using that instead.

I don't think I will need to implement any custom logic in FPGA. Having worked with FPGA I only really want to use it if there is something I HAVE to do in it that I can't implement on real time side with a scan-engine synchronized loop. multi-kilohertz control loop rates, signal generation or digital logic. Motion control will be handled far better than what I can implement by purpose built, EtherCAT third party servo controllers. My experience implementing custom FPGA logic on the etherCAT slave is not really worth unless you really need it. That is, it's worth it if you have a physically distributed network and you need FPGA logic AT that physical etherCAT node. Otherwise, for master and slave colocated in same cabinet, I prefer to stick any FPGA code on the master, which can have big FPGA, and just use the slaves as expansion chassis for scanned IO. Thank you for pointing that out the CPU issue. I believe I will get a high performance cRIO then.

On 6/20/2016 at 2:59 PM, Omar Mussa said:

I've been using a mix of EtherCAT slaves (all third party, none are NI) for several years now connected to various NI cRIO controllers (9067, 9068, 9035) and I haven't had any major issues.  So far, whenever I've had an issue its been because the vendor had an error in their XML file and contacting the vendor I've been able to get fixes in each case without too much hassle.

 

I would warn that if you are using a 9068 you should be aware of this issue:  http://digital.ni.com/public.nsf/allkb/9038F4D0429DD7C686257BBB0062D3F3

In my case this issue was a showstopper so we switched to a 9035 which I would recommend looking at.

It's good to know it can be done with multiple third party slaves. I am going to have to analyze what happens during resets, thank your for bringing that KB to my attention. Behavior during reset can be odd for certain device-- the NI 9401 DIO module outputs go HIGH during reset for example.

On 6/20/2016 at 5:57 PM, smithd said:

I guess I would say look for the module being compatible with a 9074 in FPGA mode. This excludes things like the XNet interface which is RT-only but includes things like the raw CAN card. You can also emulate it in the project -- if the FPGA compiles, it will likely work. The two big showstoppers I've seen with ecat are...

Yeah lots of small logic bits will save you with the ethercat...but theres also the risk you run out of space since the FPGA on those guys is so small.

The other concern is the number of user-defined variables. While you can have full chassis worth of IO, you can only have like 64 or 128 or something like that UDVs per chassis. 

Oh yes, I have the compatibility chart KB bookmarked

http://www.ni.com/product-documentation/8136/en/

It's funny you mention UDVs because that is exactly what generated a nearly showstopping bug for me a year ago- CAR was issued

http://forums.ni.com/t5/Real-Time-Measurement-and/cRIO-application-works-in-interactive-mode-but-broken-VIs/td-p/3095135

I wonder what the UDV limitation comes from? Perhaps NI will do a refresh on the cRIO EtherCAT chassis soon and put a bigger FPGA on it.

Very good! Thank you for pointing me to this article, was not aware of it. The only thing I am wary about is running into a bug that will be complete show stopper, which a risk with hardware configuration that are theoretically possible but no one really uses. Especially when using third party devices. 

Hi all, I am designing the control system for what will be a fairly large machine and I considering the ways the overall system can be architected. I have created systems with a cRIO master and a single cRIO 9144 EtherCAT slave. However I have not tried using multiple EtherCAT cRIOs and/or 3rd party EtherCAT devices like servocontrollers. Has anyone used more than one EtherCAT slave with a cRIO? How many slaves can you realistically daisy chain off one of the newer "value" cRIOs like the 9068? I know this answer will depend on number of scanned variables and the scan engine period. At 10ms scan engine period, what can you expect?

3 hours ago, ShaunR said:

+1 with Hooovahh. Checkboxes and LEDs.

FWIW. I no longer use LabVIEW front panels at at all for commercial user interfaces..

What do you use?  

Thank you both for your fast response.

 

So basically the cRIO is not as easy to use while troubleshooting code... Does it take long to recompile/download the code to the cRIO's FPGA?

 

The cRIO-9064 that I am thinking of using, is a linux system. Can I use a host windows based PC to write the code and download it to the cRIO? Will it work?

It sounds like you don't need custom FPGA functionality. Programming with the scan engine interface is easy, and I personally thinks it's even easier than NI-DAQmx, where you need to screw around with configuring tasks and channels. With scan engine interface, you just drag the I/O node onto your block diagram from the project and read or write from it.

if you want to run a cdaq chassis, why not jsut get one of these

http://sine.ni.com/nips/cds/view/p/lang/en/nid/212698

it combines the industrial PC and cDAQ into one chassis

Network streams are built on top of TCP. It provides a simpler interface than TCP for streaming data point-to-point, at the cost of losing the ability to listen for multiple connections. It's nice to be able to dump an array of doubles in one end and get the same array out the other end, without having to search for data boundaries and reinterpret bytes.

 

We are currently developing a system that controls and monitors a pilot plant, using CompactRIOs and CompactDAQs connected to a central PC server. There are a large number of I/O points, a number of which need kHz sample rates. The cRIOs and cDAQs use network streams to transfer the waveform data to the server for logging.

 

Also, our customer wants to allow an arbitrary number of client PCs to view the logged data. The server accepts requests from a client via raw TCP, taking advantage of the TCP Listener function. Once a request is received, the server sends a unique ID to the client to establish a network stream for transferring the waveform data.

 

yes that sounds like a good application for them and what they are designed for. For generic command and event data, where the data type can be anything, at a rate of at most 10s of Hz, I would say just use TCP via the Simple TCP Messaging library. 

Agree drjdpowell. I went to the trouble of figuring out to create having N instances of an executable opening a pair of network streams to remote targets, handling disconnects gracefully on both ends, and figuring out all the error codes associated with them. In hindsight I should have used the simple tcp messaging library.

Supposedly network streams are goodn or high data throughput of one data type but how often does anyone really need that?