smithd

3 hours ago, LogMAN said:

Also the CPU consumption is about 20% while dragging, which is way to high in my opinion. How did that ever pass testing phase? Looks to me like they never tested with more complex VIs like this because it works fine for smaller (or empty) VIs.

This may have already been mentioned, but have you tried changing the compiler complexity threshold? http://zone.ni.com/reference/en-XX/help/371361P-01/lvdialog/miscellaneous_options/#compiler

Its possible its trying to compile while you drag or something, and maybe the drag selector interacts with the UI thread more or something.

There should not be, adapting to type is all you want and thats what vims do. As pointed out, queues are not a runtime-dispatchable type in the same way you cannot dynamic dispatch off a boolean or an array. The contents are irrelevant. 

Its worth noting that vims support dispatching based on method name rather than class hierarchy. There are examples of using vims to make lvclasses act kind of like interfaces (ie if you have two separate hierarchies with a method "Get queue" which returns a thing at connector pane position 3, you can put that in a vim and it will adapt, including if that outputted thing has a different type).

As a side note, you can and should wrap the queue status and index primitives inside of a disable structure.

11 hours ago, 0_o said:

I thought about leveraging mongodb with kibana and celery with xml rpc

Python will load an API sequence from the db that suits the specific station and specific test while the API driver is preloaded also into the station according to the SQL (it can be a Python driver or whatever).

I'm curious how this would work in more detail if you could share. It sounds interesting, but it also sounds like...a lot. For example I'm not sure where kibana fits in, and I'm curious what mongo gets you that you couldn't get with a more common database like postgres.

This kind of reminded me of what you are describing. It wasn't really applicable for me but it came to mind when I read your post. It looks like their "driver" can (in at least this case) just be an ini file.

Since it sounds like you're open to python, this have always been on my "neat, but I don't have a use now" list: https://airflow.apache.org/
Its a task graph and you can use something like celery or zeromq or amqp to move data to those tasks.

Also, on the topic of kibana+databases, this tool is way cool: https://github.com/apache/incubator-superset
its basically a graphical sql editor in python/html which talks to any sql db python can talk to, and with a bunch of cool visualizations. I've not used it 'in production' but its similar to (and 1000x better) than something we had built in house and I demo'd it to some folks and they liked it almost as much as I did. I know its not related to this topic at all but I like it.

sorry

mjpeg doesnt work like that, its literally a bunch of jpegs in a wrapper. Random access should work as well as forward access. I'd bet forward access has some caching and pre-fetching though, so for random access check your cpu load, memory, and disk usage while trying to play the video. I'd bet you're hitting some limit. Specifically you are asking a lot of windows to smoothly unpack a randomly accessed frame every 34 ms using software decoding. 

15 hours ago, Rolf Kalbermatter said:

Who knows, Oracle might buy his rights some day and then go and sue everybody. 😃

I think this important and descriptive org chart diagram is obligatory for any reference to oracle:

5 hours ago, jacobson said:

This may be a misunderstanding from my end but I thought if you did not include any license then your code defaults to "not really open source". I'm not a lawyer but choosealicense.com/no-permission/ is where I was reading that and I have used the site before to get the TL;DR for licensing.

Its definitely open source, you just can't use it or copy it...and I imagine flarn could sue you if you release something kind of like his code and its discovered that you knew about this code. 

5 hours ago, ShaunR said:

MIT is a good permissive licence. Unless you categorically state otherwise, LavaG.org cannot technically even distribute it to us which, I expect, would not be the intent. It's a minefield and just choosing one, regardless of what it is, saves so many headaches for your intended users and for LavaG.org.

In the US, I believe lava gets away with this because of safe harbor provisions in the otherwise frightening DMCA. Even without that, many forums have terms of use which generically cover these things. For example from ni.com:

Quote

User Contributions. Any information or material ("Communications") that you transmit to this Site is considered non-confidential. NI has no obligations with respect to the Communications, and NI is free and you authorize NI to copy, disclose, distribute, incorporate, translate and otherwise use the Communications and all related data, images, sound, and text for any and all purposes. NI reserves the right, in its sole discretion on a case by case basis, to remove, reject, or otherwise modify any such Communications or any portion(s) thereof. 

As I read that, it sounds like the site basically says ni can do anything it wants with anything you upload, including distribution and copying. Other parts of the terms of use also make it clear that just because NI has that right, doesn't mean the original uploaded conferred that right to any downloaders, only to NI. So in other words (again, as I interpret this), uploading code means other people can download it, but they still cant use or distribute it without a license from the original uploader. 

Yeah if you have only source,  2 GB is plenty even for labview. Not sure about build process issues, but for me I ran a little function post-build to upload the exe/etc to an internal server running an artifact repository. Given that you run lava, I'm guessing you could set something like that up and host it yourself, or maybe your workload is light enough you could use the free tier of amazon/ms/oracle/google's cloud services.

As to specifics: I used artifactory, but a nice simple route would be to just set up a separate git server with lfs support and then your post build step is a push to a different repo. Or you could even set up your /build directory as a git submodule or subtree (i forget the diff, I think submodule is right for this) where the main repo points at github while the submodule points at your server. Gitlab I think has a free instance for self hosting, and gitea is a free github clone, and amazon has a hosted version thats free up to a limit as does google.

Edit: or just use gitlab: https://about.gitlab.com/2015/04/08/gitlab-dot-com-storage-limit-raised-to-10gb-per-repo/

Along the same lines as the raspberry pi, its pretty annoying that NI has gotten rid of these fine old beasts: http://sine.ni.com/psp/app/doc/p/id/psp-655/lang/en

Theres obviously a ton of ethernet->serial boxes out there, but most of them seem to require local windows drivers to emulate them as local serial ports

Not VISA, but it seems simple enough to use linx? https://www.labviewmakerhub.com/doku.php?id=learn:libraries:linx:reference:labview:uart-open

Per the "Details" section of the help here http://zone.ni.com/reference/en-XX/help/370281AE-01/imaqvision/imaq_imagetoimage_2/

I think you just need to reuse the mask you created earlier. If the ROI is a polygon, the mask will be a polygon so when you use imagetoimage it will only copy the pixels inside of the polygon.

10 hours ago, rharmon@sandia.gov said:

2. Question, what does the flush file do? How does this help me?

It forces the OS to finish any pending writes. Closing the file does the same thing. So if the concern causing you to continuously open and close the file was to ensure that your data was safely on disk rather than pending, flush would give the same result. It sounds like that was not your concern, so flush has no benefit to you.

https://forums.ni.com/t5/LabVIEW/Converting-Controls-to-Silver/td-p/1705536

https://forums.ni.com/t5/Quick-Drop-Enthusiasts/Quick-Drop-Keyboard-Shortcut-Silver-Conversion-Tool/gpm-p/3510319

as a general statement, I'd strongly recommend against doing this on all your code. UIs, ok, if you really like silver controls then by all means, but theres no point to changing subVIs and...its irritating.

also, there are more attractive packages out there for UI. A reasonable but by no means complete starting point is here:

https://forums.ni.com/t5/UI-Interest-Group-Discussions/bd-p/7116

For example drjdp's flatline controls (which is currently post number 2 in that link) are nice.

2 hours ago, Michael Aivaliotis said:

Stupid question. Why don't you open a file handle once then just keep the file handle open while writing, then close it at the end of the program? When you write to an open file handle, the file pointer stays at the last write point.

Yeah, this is what I would do too. I'm assuming the goal is to make sure that if the program aborts the file isn't corrupt, but you can do that with flush file. If you're taking data every second the continuous open/seek/write/close/open... is going to take a toll.

9 hours ago, rharmon@sandia.gov said:

The control portion of the program has run for months with out errors. But the first test to gather data lasted about 4 hours before I got the LabView Memory Full Error and crashed the program.

Whats the exact error you get? The modal out of memory error popup dialog, or a code? How big is the file at the time of the crash? Bigger than 2 GB? Are you using 32-bit labview on a 32-bit machine? Bigger than 4 GB? Are you using 32-bit labview on a 64-bit machine? Etc, etc. In theory file open shouldn't need to read the whole file into memory, but 🤷‍♂️

Easiest way to isolate this, though is to generate some representative chunk of fake data and write to a file in a loop relatively quickly (think every 150 ms rather than every second). If its the file code thats the problem, you should see the error within an hour.

2 hours ago, rharmon@sandia.gov said:

I'm always looking for better ways to crack a nut... How would you have written it differently?

I would just say its kind of bad form to sequence things like that, as its much harder to read ( as this thread shows) and much easier to make a mistake (for example if you didn't have that clear error in there, or if you added another case but didn't wire the path through [and on that topic, linked tunnels are your friend]).

Since we're talking about style, I'd personally do this:

• Take most of the bulk of case i=1 and make a subVI called "create file name" and a subVI called "create log header" 
• I definitely would not build the path manually as you are doing with the concatenate string function -- I'd use the build path VI
• I'd wrap the folder check and the create file function into a reusable subVI -- I've never personally found a use for the default behavior where I ask the OS "make me a/file/in/a/folder.txt" and it responds "sorry bro that folder doesn't exist", so I always bundle the two together.
• The timestamp formatting section can be improved in one of two ways:
  • Format date/time string using these format codes instead of manually bundling things (eg "Date_%Y_%m_%d_Time_%H_%M_%S_%3u")
  • Use format into string with the same timestamp formatting code, except you have to put it inside of %<>T , ie "%<%Y_%m_%d_%H_%M_%S_%3u>T". The advantage to this is you can use the exact same format string to scan it back out again. 

If you do these three things, your create file case becomes just a few nodes and only takes up a small amount of space on the diagram...plus, you now have a "create file" function which you can reuse on future projects, and with some tweaking you have a "create standard file name" function you can use in the future as well.

9 hours ago, rharmon@sandia.gov said:

I'm writing to a text file with an .xlsx extension mostly for easy access and readability

Excel may be smart enough to handle this, but you should probably set the extension so CSV, TSV, or TXT -- xlsx is in fact a zip file with a specific format, so writing regular ascii text to it will  should not work. If you want to make a proper xlsx file (eg an excel file) you can use either the report generation toolkit (kind of slow, uses activex to connect to an excel instance so excel has to be installed on your daq computer) or an addon toolkit like xlr8: http://sine.ni.com/nips/cds/view/p/lang/en/nid/212056

If you have lv2018 and are at least familiar with python, you can use the python node + a small helper method to write to an excel file using xlsxwriter or openpyxl .

I was under the impression that the .net interfaces just wrapped the old activex interfaces. Is that wrong?

to actually answer your question I've never used it, but it seems like these might work:

text ("TextType" section halfway down): https://docs.microsoft.com/en-us/visualstudio/vsto/how-to-programmatically-insert-text-into-word-documents?view=vs-2017

table: https://docs.microsoft.com/en-us/visualstudio/vsto/how-to-programmatically-create-word-tables?view=vs-2017

If I'm reading the samples right it looks like you can get the current cursor from "Application.Selection" and then insert a table using a method on that object.

1 hour ago, Rolf Kalbermatter said:

the last step in the description on the sourceforge post could be made simpler: 

Instead of changing the library path in all Call Library nodes to <some long path>/lvzmq32.so and having to maintain two versions of the VIs because of the different library name ending, you should replace the .so with .*. LabVIEW will then replace the .* with whatever file ending is standard for the current platfom (.so on Linux, .dll on Windows, .framework on Mac)

as I recall Martijn had some issues with the combo of VIPM mass compiling + *s in the CLFN path. I filed a CAR for him at the time but I doubt its resolved, and his workaround was (again, as far as I remember) that when you install the package it runs a script which adjusts the path based on the platform. The middle ground is what I think most people end up doing, which is to create a VI with some conditional disable code to determine the path.

2 hours ago, MarkCG said:

update to this thread: we got it working on the cRIO 9068. See this thread https://sourceforge.net/p/labview-zmq/discussion/general/thread/87780372ed/ for details. Thanks to everyone here and Martijn Jasperse for all your help. 

As I was reading this I remembered something else..far, far too late ...NI provides a zeromq build as part of the core package list.

Package: zeromq
Version: 4.1.6-r0.16
Depends: libc6 (>= 2.24), libgcc1 (>= 6.3.0), libsodium18 (>= 1.0.11), libstdc++6 (>= 6.3.0)
Section: base
Architecture: cortexa9-vfpv3
Maintainer: NI Linux Real-Time Maintainers <nilrt@ni.com>
MD5Sum: ea3774e76c28b7c5b07318b4502fec9e
Size: 147468
Filename: zeromq_4.1.6-r0.16_cortexa9-vfpv3.ipk
Source: zeromq_4.1.6.bb
Description: zeromq version 4.1.6-r0
 ZeroMQ looks like an embeddable networking library but acts like a
 concurrency framework
OE: zeromq
HomePage: http://www.zeromq.org
License: LGPLv3+
Priority: optional

Package: zeromq-staticdev
Version: 4.1.6-r0.16
Depends: zeromq-dev (= 4.1.6-r0.16)
Section: devel
Architecture: cortexa9-vfpv3
Maintainer: NI Linux Real-Time Maintainers <nilrt@ni.com>
MD5Sum: 686b2b13e3908313aa35da8b46955ddc
Size: 3765648
Filename: zeromq-staticdev_4.1.6-r0.16_cortexa9-vfpv3.ipk
Source: zeromq_4.1.6.bb
Description: zeromq version 4.1.6-r0 - Development files (Static Libraries)
 ZeroMQ looks like an embeddable networking library but acts like a
 concurrency framework  This package contains static libraries for
 software development.
OE: zeromq
HomePage: http://www.zeromq.org
License: LGPLv3+
Priority: optional

All you should have to do is opkg update, opkg install zeromq, and opkg install zeromq-staticdev. Its available at least as far back as 2017.

Note: you will still need to compile the wrapper library

2 hours ago, hippo Th said:

Will I usually get this header or .lib file from the manufactor or is it secret? Alternativ, the manufactor offers their own software with a huge software package (about 900MB). But I don't know, how to implement their own software to my test bench with LabVIEW.

Thats kind of a circular question -- if the manufacturer doesn't want people to use their driver standalone, then they will not provide a header. If they want people to be able to use their driver standalone, they must provide a header. As I recall, lib files are only for statically linking within your application, which means you'd have to be writing in c or c++. LabVIEW and most everything else can only call dlls. If you only have a lib and not a dll, you'd have to write a little wrapper library and use a C compiler to build the wrapper+lib into a dll.

The docs are a bit old, but it would be worth reading these:

https://forums.ni.com/t5/Developer-Center-Resources/Tutorial-Configuring-the-Call-Library-Function-Node-to-call-a/ta-p/3522246

https://forums.ni.com/t5/Developer-Center-Resources/Calling-C-C-DLLs-from-LabVIEW/ta-p/3522488

Just skimming your PDF, a lot of this this looks like a reasonably straightforward dll to call from LabVIEW, but you have to get conceptually used to the interface. For example many of the functions have an opaque pointer like "CIFXHANDLE" which is represented in labview as a U64, but in order to get that pointer in the first place (xDriverOpen) you have to pass in a "0" value by reference, and the dll will overwrite that and provide you with the actual pointer on the output side of the CLFN.

There are also a good number of things that are impossible in LabVIEW, namely callbacks:

int32_t xSysdeviceDownload( CIFXHANDLE hSysdevice,
uint32_t ulChannel
uint32_t ulMode,
char* pszFileName,
uint8_t* pabFileData,
uint32_t ulFileSize,
PFN_PROGRESS_CALLBACK pfnCallback,
PFN_RECV_PKT_CALLBACK pfnRecvPktCallback,
void* pvUser)

If you need those callbacks (they are optional), you can't create them natively from LabVIEW. You will have to make your own simple wrapper library which implements the callback functions.

Given that there are about 80 pages of function descriptions, you might want to take the time to copy out all the calls you think you are going to need to use, and then review those calls for callbacks or other potential issues (the other big one that comes to mind is if functions lack a clear termination mechanism -- ie a "read" function that has no timeout or other way to cancel the read)

21 hours ago, hooovahh said:

Be able to run G code in a browser!  On paper that is awesome.  But NI choosing to make this an add-on at an additional cost makes it less accessible. 

Yeah its not super high in the grand scheme, but $2k for an addon to a product thats already $3k or $5k (not clear if you need the app builder license for building web apps?) seems pretty steep. Probably more to the point, it doesn't seem to be bundled with anything (not even software platform bundle). They seem to be deliberately targeting only people who really for sure want that functionality, which is kind of interesting within the context of NXG as a whole which they are literally giving away to try to get people interested in using it.

10 hours ago, Rolf Kalbermatter said:

The editor almost seems to know what you want to do, because it always does the opposite of that, no matter what.

😢

Sometimes I just remove an entire splitter section and start over

9 hours ago, Rolf Kalbermatter said:

except "Are you really sure you want to close this window?" Damn it! No of course not, I clicked on the upper right corner by accident and never ever would think about getting rid of this huge monster window on my desktop screen.

Theres a checkbox  One of the first things I do on a new labview install, along with disabling the tiling shortcut, setting terminals to required, and removing that stupid number from new VI icons  

7 hours ago, JKSH said:

I find the Silver palette quite decent Simply setting the background to white (as opposed to "LabVIEW Grey") also does wonders.

A note on your last link: That "stark example of modernity" depicts an old widget technology, basically unchanged for over a decade -- it's still maintained today, but only in bugfix mode. Here's an actual example of modernity.

Ughhh. I hate the silver controls. Too much chrome. I generally use a combination of drjdp's flatline along with system and a collection of internal controls which includes a giant amount of scripted booleans using feather and iconic.

To your second point -- I knew it was old based on the version number but I couldn't find a standalone screenshot of similar quality anywhere so I decided to punish them. Presumably thats why wikipedia still uses such an old screenshot. For what its worth I also include your example in this because the part thats attractive about it is really just PNGs. It doesn't demonstrate the core widget library that most people would use. And if you look at the designer, its seems like some stuff (type and ID in the middle of the right side for example) is just a hasty skin over top of an old library -- or at least thats how I interpret it because the weird left-side justification is the sort of artifact you get when you try to fiddle with labview controls in a similar way. On the theme of punishing them, I like this one, technically part of the help for the current major version (qt5).

2 hours ago, ShaunR said:

Hmm. I'm not sure what your expecting me to say here.

what you said worked

The probe window is indeed annoying, I just have never thought about making indicators since then you have to restart the application and that can get quite annoying esp on rt. Its kind of funny I never thought about it because thats the workflow you have to use on fpga, but 🤷‍♂️

3 hours ago, Rolf Kalbermatter said:

What I still not understand is that so many people complain about how last century LabVIEW Classic looks, but nobody finds the smooth baby rounded icons and light gray in more light grey colored controls in any way odd.  In some ways it reminds me of HPVee, which I thought was dead 😀. Did NI decide that HP might have done something not so bad after all these years of fighting it as pure evil?

I think people conflate style and functionality on this topic. The style of labview controls is kind of old, but not any worse than wxwidgets or gtk+ or qt or windows forms. The stuff that makes labview stand out to me is resizing failures (lol @ trying to get splitters positioned nicely), composability failures (lol...xctrls), and the inability to instantiate new controls at runtime (now resolved in nxg).

For contrast, its not like these (wx or gtk or this stark example of modernity) are all that more attractive, they just have features that allow for their developers to create better functionality. My favorite example is I think audacity which looks like complete garbage, but would be very difficult to develop in labview for..well look at it.

9 minutes ago, Rolf Kalbermatter said:

You mean multiple projects? 

Nope:

And I can confirm both windows update correctly -- when I made the control it popped up in the panel side immediately.

The reason I say its clunky is that you have to open the VI, pop it out of the main window, open the VI again, pop it out, and then switch. They need to streamline this, but the functionality is definitely there.

Really? I've always hated the multiple windows. The MDI is one of my favorite things. The inconsistency makes me laugh, though, like making context help floating (there is only one -- I'd really rather it be docked and always on) and making palettes docked (I want several instances, so floating makes sense or at least allocating space on each side of the diagram so you can have one thats pinned and one thats not).

41 minutes ago, ShaunR said:

 I usually have the diagram on one and the FP on another 

I'm genuinely curious about this one...why both? My only experience with having FP and BD side by side is when I accidentally hit the stupid tiling hotkey on a new install, just before I go into the settings and permanently remap it to something out of the way like ctrl+alt+shift+\. I honestly can't think of a time I've ever done this.

3 minutes ago, Rolf Kalbermatter said:

since got smarter by allowing at least a seperate application window for every document. That makes it at least usable on multimonitor setups.

NXG has this too. Admittedly last I checked it was slow and clunky, but...

The page you linked to is only for c dlls. If its a .net assembly dll, you can use the labview .net interface.

https://forums.ni.com/t5/Developer-Center-Resources/Calling-NET-Assemblies-from-LabVIEW/ta-p/3523180

to test this, drop down a constructor node and from the dialog, select browse and locate your dll. If it loads, you're in the right spot.

7 hours ago, bbean said:

•  
• Adding a terminal on the block diagram seemed more tedious and defaulted to not showing the Control/Indicator on the front panel  . WTF.

Dunno if this is the same time frame, but I vaguely remember that early on they seemed to be saying "our users complain about absurd right click menus, therefore -- no more right click menus!". That seems...better in 3.0, although I honestly still can't remember which icon is which. I actually like that the terminals don't show up by default. After all, 99% of your code doesn't need a UI. 

Also, I dunno about you but I'm going to accidentally close so many windows. I'm used to ctrl+w'ing twice as many times.

3 hours ago, ShaunR said:

Another 10% aligning controls and wires and the other 80% is iterating, refining, debugging and documenting. Making a whole new ide because it is "more efficient" is an excuse you use to management and sales to fund your project when you have no concrete arguments. The real reason, IMO is more to do with that people are so afraid of touching the existing LabVIEW code and they have a glut of .NET coders who suffer from "not invented here" syndrome.

Yeah, I've always been under the impression was that NXG was for NI's efficiency, not users (directly). They wanted to try to provide tools that make the debugging and documenting and editing easier, but the 20 year old codebase was hindering them in doing so. The reason is likely along the lines of what you said, although its probably a bit simpler: reading code is hard. 

43 minutes ago, Rolf Kalbermatter said:

ODBC is an old legacy technology that even Microsoft would like to forget if they could.

Poor microsoft, they can never forget 👻