Posts posted by Mellroth
I know this is a really old thread, but I just saw Darins post about implementing ZMTP in LabVIEW.On 11/27/2013 at 6:05 PM, Darin said:
Been there, done that. I have G implementations of ZMTP (at least most bits I need) and AMQP (0.9.1 not the 1.0 trainwreck). I tend to use AMQP most often since my code is more complete (and there was more adoption of it when I wrote it), but they are both great. The brokerless nature of ZMQ can be great when you need it, turns out most times I was implementing a de facto broker and could have stuck to AMQP.
Unfortunately the specs are really laid out seductively in terms of classes and methods so I gummed up the works by using a bit too much LVOOP (not to mention busted my carpal tunnels). Performance is ok, but as I de-LVOOP it is finding another gear. I create worker pools consisting of simple LV workers and similar C++, Java, or Python workers and see what share each worker does. LV is behind, but getting up there with the big boys. The LV9 to LV12 performance kick was also welcome here.
The AMQP implementation gave rise to one of my new mantras: No LVOOP in a loop.
Was this a native LabVIEW implementation or did you use a wrapper around the ZMQ windows DLL?
I'm walking through a LVRT Project using the VI Server API, trying to find a particular build spec on my FPGA target. I can get the target ("FPGA Target") by name and use that ref to find the build spec by its name, but the reference returned can't be cast to type ProjectItem:BuildSpecification. If I probe the reference wire, the only interesting thing I see is the type GUID...
Does anybody know of a way to deduce the VI Server object type from this GUID so I can perform a downcast on it?
I might misunderstand what you are trying to do, but do you really need the GUID conversion?
Once you get to the BuildSpecs and its OwnedItems you can query each OwnedItem for the TypeString.
This typestring is different depending on if you have a build script that is EXE, Source Distribution, Zip etc., but you can cast any of them to BuildSpecification.
First of all, thank you for posting this
I've used this in a couple of internal projects, and doing so I've seen and fixed a few issues.
The changes are:
* Fixed Dispose Notification Icon.vi so that it correctly removes the tray icon even if error
* Updated Set Tray Icon (string).vi so that you can have any image type stored as string on your block diagram
* Updated Set Tray Icon (string).vi VI description to reflect this change
* Added basic error handling to the example (dialog and clear)
The changes were made in a later LabVIEW version and backsaved to 8.6.
I also think this is 2014, without any confirmation.
I think it is the Linux based cRIOs that come without FTP enabled.
So if I'm working on a VI and I don't have the lock I will hit save, and LabVIEW will prompt saying it can't save it is read-only and the explorer window will be opened asking me where to save it. I will in this window right click my file and get the lock. I'll then cancel that window and save again, and this time it will save because I have the lock and it isn't read only.
I use TortoiseSVN exactly like this, I only want to point out that the main reason I press cancel and then save again is that this prevents me from saving over another file by accident.
You set this up in the TortoiseSVN client configuration file.
1. Enable auto props (uncomment ###enable-auto-props = yes)
2. add a line at the end of the [auto-props] section that reads *.* = svn:needs-lock=True
You can also have a pre-commit hook set on the server to detect if any commited file lacks the needs-lock property.
- Popular Post
- Popular Post
...or of course the built-in flatten to json which is even faster.
Just a bit of warning regarding the built-in json methods.
If you flatten a cluster containing a string with \00 characters in it, it all converts nicely to json, but the built in functions fails to convert the strings back to the original value.
The reason is probably that the json parser stops decoding the UTF8 encoded string at \00 (IMHO this is clearly a bug since strings are not NULL terminated in LabVIEW).
I have a Mean of ~0.013 for the 0.65V sine wave. Not enough to offset it. However my sine waves are not always nice. It captures the Glitch Energy and seems to be offset to the positive by much more.
It can reach the 1V at times. Not sure how it can get those kinds of values...
Both the 6723 and the 6225 are in the same PXIe-1073 chassis.
I think I would argue that the LabVIEW RMS calculation is more correct; if you want to get the same reading as the DMM, you would have to estimate your data to be a clean sine-wave (or calculate the RMS over more periods).
i tried both command keys on the mac...to no avail
Maybe I'm stating the obvious, but if you develop on LabVIEW for Mac, you use the command-key + the short cut, but when you switch to the virtual machine you will have to use the ctrl+shortcut instead.
In the link Hooovahh gave you (https://lavag.org/to...ing-in-labview/) you can find a solution for ctrl-key shortcuts not working in the Virtual machine.
I am forgoing the option to dual boot Windows on my Mac so performance is not affected. Rather, I am looking for a reliable virtual machine that LabVIEW performs the best on.
On my MacBook Pro, I use a number of Virtal Machines running with VirtualBox regardless if I boot MacOSX or Windows.
The only issue so far has been that one USB device driver failed to load in the Virtual machine.
I use LabVIEW for Mac on an iMac regularly. What do you expect to not work?
You don't have many hardware IO interfaces on the Mac but running LabVIEW for Windows in a virtual machine won't give you more options for sure. And BootCamp or whatever that is called nowdays likely will be also not a full solution since Windows doesn't come with drivers for every hardware component in a MacBook Pro.
I do all my development on a MacBook Pro in Bootcamp and VirtualBox, and I have yet to find something that doesn't work in LabVIEW for Windows.
The only thing I've found that doesn't work all the time, is that USB access in virtual machines can be a bit shaky. But, this seems to be more related to VirtualBox than the MacBook.
Sounds interesting, but I don't think the functionality is clear enough (things like "Is this for live data? Historical data? What does the web app look like? What does the phone app look like?", etc.). I would suggest creating some videos and examples and maybe also adding a public test account which people can connect to (at least for reading, if you don't want someone flooding your server with useless data) to see how the system works.
Thanks for the comments Yair, sorry for the delay in response.
The WireQueue service is mostly intended for Live data monitoring, and the data posted online is defined by the user of the LabVIEW API. Videos and more information are in the works.
Since it is an open beta we expect the phone interface to change a lot while we get comments from users, but the Andoid app is available on AndroidMarket, and the iPhone app should be available within 24h.
We have discussed to open up a public test account sometime after NIWeek, but have not decided on which parts we can make public (read access only should not be a problem). I'll post here once we have that in place.
If you are attending NIweek, I would suggest visiting booth 923 for a live demo.
WireFlow enters the world of IoT!
Today we are proud to announce an open beta of WireQueue; our cloud based service that allows customers to build secure IoT solutions for data logging, monitoring and control of LabVIEW/LabVIEW RT targets.
The WireQueue system consists of: a LabVIEW driver that makes it easy to exchange messages with other clients, monitoring apps for mobile devices and a cloud based server.
WireQueue uses open standardized protocols and all communication is secured with SSL/TLS. Sensitive commands can be further protected with hardware authentication using WireFlow dongles.
Visit https://www.wirequeue.com for more information, and to request a trial account.
You can also find us at NI-Week in booth 923.
//The WireFlow Team
I would like to operate a Labview RealTime system (PXI) as EtherCAT Slave. The master system should be a Beckhoff control. Is it possible to operate the Labview RealTime system as EtherCAT slave?
Thanks in advance
At the moment I don't think you can.
It is my understanding that EtherCAT requires the Slave ethernet interface to be more advanced, because it is the slaves that manages the us synchronization between nodes etc.
So in order to get a PXI chassis to be an EtherCAT slave a special network card would have to be used.
I think there was a third party library posted on NI.com that allowed you to interface the beckhoff modules, but I don't remember if it was also possible to use for this scenario.
The question that comes up is how do we easily generate a list of authors, for BSD code that is used? Certainly a pre-build on an application builder can be used to run a VI that generates this text file, which is included in the project. But with this is a few issues.
I'll try to dig up my old code that does just this.
Finding all Copyright notices on the FP of all OpenG VIs was quick, the problem was how to present this to the end user. If each VI has a © notice, does that mean we have to list the copyright for each VI, or just to find all contributors in the code and acknowledge them?
Regardless I think it is in the interest of OpenG to define how to acknowledge the contributors, and thus add a VI that returns this information.
And, I very much prefer to have a tool that scans the hierarchy for © text than manually have to remember to scan the VIPM hierarchy each time I build an application.
Code modules other than OpenG might have to be treated differently, but I guess there are more OpenG code.
I also think I made a feature request for VIPM to be able to not only scan the project for used modules, but also return the copyright messages for these modules (even if this doesn't solve the issue with OpenG where individual VIs have different contributors).
I feel like we are hijacking the thread a bit, but it is a curious topic. I've just always used OpenG, it's always been there with the huge benefit of not having to develop, test, and document functions. Of course it is possible I've been using it wrong all these years. As for attribution can't you just use the copyright notice on the whole package, and not the individual functions in them? I was thinking of writing a VI that just takes all the attributed individuals in the OpenG libraries, and making an OpenG BSD License.txt that can be included with the software documentation.
But I do see the point others are making, that the effort in complying with a license, might be more work than the functions themselves. And if that is the case it is quite discouraging for the user of the library and the developers. I know OpenG has wanted to make things simpler with various license changes in the past, but what I feel would be really nice is a simple "This is what you need to do if you use OpenG in an application".
The copyright notice (and licensing) on the package itself might be different from some of the VIs in the package, and If I use a single VI, I still have to check all subVIs to comply with the BSD license.
I have also thought of writing up a simple little VI that scans the hierarchy and produces a OpenG license file, this VI could then be called as a Pre-build step to add the correct attribution to the built application.
Actually, I think OpenG should have this VI at the very top of its hierarchy, and the let it return the licensing info as it should be.
Is there a reason you don't use the Filter Error made by OpenG which accepts a scalar or array of errors to filter? This was made native in 2014, but only accepts a scalar for some reason.
One of the reasons we don't use OpenG in production code is that we find it hard to get all license information required by the BSD license, since different VIs and groups have different authors and thus requires different attribution.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Each time a new OpenG VI is added we basically have to check its FP to find the author and add a separate CopyRight message if that author is not already attributed.
In general, that is correct. But always check the documentation to be sure. This last year we got bit by the Destroy Stream Endpoint (for Network Streams) not executing on an error.
I know this was an issue with LabVIEW 2010, but got the impression that it was fixed in later versions?
Is there a way to "Find Callers" or "Find all Instances" that excludes the instances that are currently in a disabled case of a (conditional) disabled structure?
What if you use "Get VI Dependencies", with commented diagram disabled, on all VIs.
Put each dependency in a variant lookup, and then you should be able to return all callers for a specific VI from the Variant lookup.
The bad news is lack of documentation makes it difficult. I tried by taking an existing plugin and modifying it and I didn't get very far. Even so I think this could be a good tool for quickly turning settings on and off with a simple right click.
The documentation is only bad if you don't go to the original source...
Right clicking to toggle Conditional Symbols would be very nice indeed, but I think one problem would be that the valid range is not specified anywhere.
The conditional disable symbols only define strings and it is up to the code to handle the correct case etc.
But I guess it would be quite easy to make a project provider that defines valid ranges that could be selected using right-click
No problem, I figured you of all people would be interested and I was hoping you'd see this. There is plenty of room for improvement but I've been using it without any problems for a while. I sorta feel bad that I didn't share it sooner.
When we talked about it I had multiple LabVIEW versions installed on my dev machine, but since then I've moved on to use separate VM's for the different LabVIEW versions.
I do still have one laptop with multiple LabVIEW versions, used occasionally for building old SW packages, and this tool is very handy to have.
I know this is an old thread.
But does anyone know what can cause an Asynchronous launched VI to stay running even though the entire code is done?
I ended up just switching back for that particular VI to using Run VI method and that worked.
I'm not sure it applies to your problem, but using a Strictly typed Static VI reference as an input the the Open VI reference has been a big problem for me leaving all kind of processes running in the background.
The workaround has been to replace the Strict VI reference with a strict-constant, and use a non-strict reference to get the VI name/path.
This workaround also applies to Actor Framework since I believe it uses the same design as the OP.
If you set the timing source to <absolute time> then the actual start is expressed as an absolute time.
I've used the timed loop many times but never really paid any attention to this (and never had the need to either).
Our data logging engine is based on a timed loop, and the Actual Start left node is used to log the current absolute time. 99% of the time it works perfectly, but once in while it will give the value 11/11/1903 10:57:12.702 PM. Each time it gives an erroneous value, it's this exact value. Has any of you ever seen that? We use LV2011 32bit.
I've never seen the Actual Start return other than a local timer value.
It should start at 0 (or the offset you specified in the loop setup), then increment with the specified loop delta using the current timing source as timing unit.
How do you do the conversion to an absolute timestamp? Adding timer value to a loop start timestamp?
zeromq - simple fast lightweight communication - does it fill a gap in NIs offering?
in Remote Control, Monitoring and the Internet
Thanks for the reply,
the thing for us is that the customer needs ZMQ (ZMTP) on a Pharlap-based cRIO (no inter-process stuff). We are essentially evaluating our options; either implement in pure G, or recompile for Pharlap and change the wrapper VIs to handle this.
Any chance you could share the G code?