eberaud

Our plan has been delayed until further notice, so we haven't made the move yet. So thanks for your valuable input.

Hi, I am planning to buy a few books for my company, to be shared within the software team. On my list are already the classic and must-have LabVIEW Style Book by Peter Blume and LabVIEW For Everyone by Jeffrey Travis and Jim Kring. If I were to buy a 3rd (probably not right now), I would consider Effective LabVIEW Programming by Thomas Bress, but since it's more recent (2013), I haven't seen much feedback about it. Has anyone read it and can comment on it? Any other suggestions welcome!

Fabiola De La Cueva made a great presentation about this at NIWeek: https://decibel.ni.com/content/docs/DOC-43414

CLA practice exams are good examples of how the MVC diagram can be applied.

There is rarely feedback on practices on LAVA. You'll have better chances here: http://forums.ni.com/t5/Certification/Sample-Exam-Solutions-for-Review/td-p/1824703/page/27

I would even suggest to remove this post. The list of potential actual exams shouldn't be posted anywhere.

Glad to announce that I successfully passed my CLA! Thanks crossrulz for your guidance!

I see, thanks for the tips. So far I already have a XNET solution, but on the DAQmx side, on a tethered cDAQ. So I will have to migrate this code to the LVRT side.

Thanks everybody. Well in our case we'll also need Ethernet, CAN, and RS232 communication in order to send commands to the different hardware devices in a fast and deterministic manner. I don't know yet if the SCAN engine support those or if we'll have to write FPGA code for those. Now that I think about it, Ethernet and RS232 ports might be available on the RT Controller and will directly accessed through the LVRT? Only the CAN might be a module in the chassis and therefore require the FPGA layer?

Thanks a lot smithd. My application is fairly complex and there are probably like 30 subpanels if I count subpanels of VIs inserted inside subpanels of other VIs and so on... So stripping down the subpanels is just not an option. From your answer, it seems I'll need to split my application into 2: one HMI for the PC, one RT for the cRIO or PXI. For the cRIO I understand that the HMI and the RT can communicate through shared variables or network streams. But what about the PXI? Is it a common practice to have an RT application in the PXI controller and an HMI on a PC? And how would those 2 applications communicate? Cheers

Hi, My company has been developing and maintaining its own SCADA software in LabVIEW for a few years. It is fairly comprehensive: datalogging, graphing, alarm monitoring, automation, loops for equations and PIDs, and so on. It is a PC-based solution and communicates with many different kinds of hardware through the COM(RS232), USB, and Ethernet ports of the PC. This solution works well and allows keeping the costs low for most of our customers. Most of the loops run around 10Hz (100ms). However, more and more we are running into customer specifications that require high control rate (few milliseconds), high determinism (to the millisecond), and high reliability. Not surprisingly, the PC solution becomes unacceptable. We feel it is time to look into a real-time, embedded solution for those customers. That's why I'm currently investigating the different NI embedded RT solutions (namely PXI and cRIO). I can find plenty of resources on each of them, but close to nothing when it comes to comparing the 2 solutions and choosing which one to go with. Would you mind giving me some guidance? I guess you'll need more information, which I'll be happy to provide. A few elements already: - There is no request for MHz loops, so the FPGA side of the cRIO is not required I believe - Our application contains many VIs that are both the engine and the HMI, so there will be some decoupling effort if we need to split it into an HMI application on the PC and an RT application on the cRIO. Would a PXI solution avoid this issue by plugging a monitor directly to the display port of the controller? But then if I have all the code in the PXI controller, is it likely that I will lose my control rate and determinism? Thanks! Emmanuel

Also, I would abandon the regular API and rely only on the Advanced API. The regular API lacks a lot of flexibility, it's only intended for very basic usage.

I also use DVRs inside my object when I know I'm going to fork it. If you want to avoid DVR, I guess you can us a SEQ (Single Element Queue). Dequeue the object to "check out" and re-enqueue it to "check in". While the queue is empty, the next place that needs to R/W the object will wait inside its dequeue (as long as you let the timeout to -1 or make it long enough).

Thanks. So if I build my application while this error still exists, could it explain why my DLL call is not working?

I see a message about the following missing DLL when I open my LabVIEW project: api-ms-win-crt-runtime-l1-1-0.dll Have any of you ever see this? Some googling makes it looks like it's due to a missing C++ Redistributable...

I think that's the key. I spent a lot of time tinkering around but thanks to that I now have a good understanding of the TDMS API and how to optimize the R/W operations. If, like me, you do your own decimation after the read operation, there is a sweet spot where it starts being more efficient to read each sample you're interested in one by one instead of reading a big block and decimating it.

Now you're scaring me...

Thanks! It's probably going to be the path we'll follow.

Dear all, My company is starting a project where some Matlab files (.m) need to be executed by LabVIEW. The 2 obvious solutions are Matlab script nodes and MathScript nodes. Unfortunately, even though the latter one is the most cost-effective and light in terms of installation, many of the functions we need are not supported by the Run Time Engine, so it's kind of a deal breaker. For the Matlab script nodes, I know Matlab needs to be installed since LabVIEW will request Matlab to execute the scripts through ActiveX. What I don't know is: what version of Matlab? Is there a cheaper "Run Time Engine" of Matlab we can use instead of buying the full-blown developement version of Matlab? Any other comment, remark, suggestion, alternatives? Thanks!

My application writes thousands or samples for approximately 1000 channels in a single group. The Read/Write operations can be a bit slow on a regular hard-drive, but we use SSD drives or Ramdisk, and then it works perfectly and at very high speed. I'm a big fan of the TDMS now. Was tough to get around the Advanced API palette at the beginning, it took a bit of understanding...

I think it's polymorphic. Try wiring a string to the path input.

By the time we really make the decision to upgrade and we find time for it, 2015 SP1 might be out there anyway

In case somebody has a few spare minutes to look at my CLA practice, here is my attempt at the ATM exam. Please ignore the elevator ones since this is one better I think. CLA ATM Exam EB.zip

Thanks for the tip, I really appreciate it. For some reasons, since my early days as a LV developer I've had the impression that people wait for the SP1 because of potential bugs when a new version is released. But maybe that is not justified anymore?

I think the plan is to move to 2014 SP1. The SP1 of any version feels more stable that the initial release (at least psychologically, even if not proven by facts).