Francois Normandin

If you need to track frequency in a noisy realtime environment, I've seen Kalman-based filtering being used. Unfortunately, I don't have an implementation example to provide. NI has this discrete filter in the Control Design and Simulation toolkit... which does not come cheap.

It's been moved to another website: http://vfpsoft.com/aes/aes_home.html

The Message Enqueuer instance is created within Actor.vi and encapsulates the receiving queue of the actor. The Actor launcher does not expose any way to specify a more specific type of message enqueuer, so I'm afraid that even though you wish to extend this class, it is impossible to instantiate it with your child type. The reason the Message Enqueuer does not let you access its private data is that it is specifically meant as a wrapper to prevent anyone from accessing the Priority Queue class. I assume the intent is to make sure you cannot mess with the message delivery principles such as rerouting messages before they arrive at the Actor Core. If it were allowed, it could cause thread safety problems, security issues (possible hacking target) or mess with the #1 feature of actors: trust that messages are processed by the core in the order the messages were enqueued.

Hi Diego, to speed things up, you should consider separating the TCP read and the file writing in two separate loops. For example, if you make two parallel loops: one that reads and adds data to a queue, and a second which reads the queue and writes to file, then you can read multiple datapoints at once and write less frequently to the file. Investigate the use of a Producer-Consumer architecture. I took the liberty of reorganizing your example to demonstrate the concept. I'd probably approach your task where your Python code is the client that publishes data and LabVIEW would act as a server (instead of the other way around), but I wanted to keep with the spirit of your example. Client.vi

to the OP: Be mindful that the "Traverse for GObjects" serves the array in the reverse order from Panel:Controls[] method, probably because of the way it stores the references in the recursion loop. @infinitenothing You're totally right. Tab order it is, with newly created controls added at the end of the list.

The method you invoke on the Panel reference always returns the Controls in the order that they were created. aka. If you delete the second element and create a new one (even with same label), it will be added to the end of the list.

Indeed, not a State Machine... "JKI State Machine Objects" gets its name from the use of "JKI State Machine" as its core "Process.vi", which is not a state machine. It is an Event-driven Queued Message Handler (QMH). State Machine was a misnomer and the name stuck around as it was (still is) a very popular template.

The reason for this typecast is to break type propagation that plagues edit-time performance which occur when you have a large class hierarchy. It is not because it makes scripting easier (on the contrary). In essence, when you edit a class' private member, the class' mutation history is modified and the LabVIEW IDE goes through a series of checks and recompiles to propagate the changes. For very small projects, this is completely trivial and does not affect edit-time performance, but for larger hierarchies (think Actor framework...) it becomes a real issue. One way to reduce this performance lag is to never put typedefs in the class private data... but this is up to the developer to stick to that rule or not. When you use an integer, using typedefs does not affect the edit time performances at all. As Rolf mentions, this pattern was popularized by GOOP (now OpenGDS). When creating a framework, you can never predict how the developers will use it... Obviously, if you use a framework and it starts to lag as your project's complexity increases, you are quickly going to blame the framework for the performance degradation (just like we blame Windows for running slower after we've bloated our computers with a bunch of apps, but that's another topic...). So it is very tempting to use tricks like this typecast to an integer to break this slow type propagation. As was mentioned by Smithd, it is risky... but if it stays in the private methods of your class, it is totally safe. In JKI SMO, you'll notice that this is used through two private methods and the DVR type is typedef'ed. You can very well create SMOs that do not use this trick.

got it.

Shaun, can you elaborate on why you needed to reinstall the other toolkits when you update your encryption library? If the project-specific librairies all pointed to vi.lib, why did their linkage break?

There are a couple of LabVIEW drivers and example codes on their website. Depending on the positioner model you have, choose the ASCII or Binary version at https://www.zaber.com/zaber-software

Use Vivado 2017 tool.

Have you checked the compatibility chart for getting the right version? http://www.ni.com/product-documentation/53056/en/ sbRIO-9627 is a Zynq FPGA. Check if ISE 14.7 might be reqiured.

I meant that LAVAG should verify that the code it hosts does not infringe on licenses, or at least have a process to summarily verify. You are right that VIPM handles the actual license from the user's perspective.

This is a good idea, but I think it would require a more thorough editorial review of submissions to put them on the such a repository. Other than the obvious code reviews, "LAVAG" would need to examine for possible license issues, consistency across versions, develop more precise guidelines for submissions, etc. The hardest part would be to maintain the same standards over the years, as people's commitment to their "review committee duties" will undoubtedly fluctuate over time. As for the actual repository, you don't need a server running. The package publisher needs VIPM Pro to modify and manage the destination folder. The content of the repository is stored as files on any accessible drive, so it's a matter of adding it to the list of network URLs. (requires VIPM Pro as well, as mentioned above, unless on LVTN or JKI Package Network)

Password protected == freeware... != open source.

The core process skips showing the UI when on RT. You can modify this in the Basic Test Manager's process by removing the conditional disable structure. However, you should probably make a request on the open source project (https://github.com/JKISoftware/Caraya) or fork the original repo. Modifying this in vi.lib will not make it persistent and is a bad idea... It might be that the logic could be smarter in that if the RT target does not have a UI, it would skip it, but not assume that all RT targets don't allow UIs. There might also be the possibility to modify the test suite setup to inject your own override code, for which you could simply change the behavior of the basic test manager.

If you already have the packages installed on your present PC, you can retrieve them manually from the cache directory: <ProgramData>\JKI\VIPM\cache This is just a temporary workaround... maybe you can notify JKI on the VIPM forum if this issue persists.

In 2018, you can use the NI Package Manager to install NXG and a bunch of other stuff. All three versions of NXG are available from that tool.

Maybe of interest to those who have used this tool with OpenOffice 4 and are getting trouble. Check out this alternative tool by Gribo. (I have not downloaded nor tested it, but this is worth looking into)

New version is available. (LV2018 32-bit) http://www.ni.com/download/labview-development-system-2018/7406/en/

Hi Ashwin, Try with "Sheet1" instead of "sheet1". Otherwise, I am getting corruptions as well... but they can be repaired. Check out my post from April 16th 2016 above. It might be the reason this does not work (newer version of OADL 1.3)

I think it's been 7 years since my last LAVA BBQ. Excited that I'll join this year!

Have you tried shifting your register address by 1? Depending on the library you use, it might not shift it automatically. Holding register addresses range from 40001-49999. (The library will prepend the 4xxxx to your register address)

It seems the DLL folder is missing from the source code. **EDIT** I've updated the repo to include the files. **END** In the meantime, use VI Package Manager to install the VIP file which correctly includes the DLLs. You can extract the whole missing folder from there if you want to play with the source. https://lavag.org/applications/core/interface/file/attachment.php?id=11167