smithd

I saw a hissy fit recently between the AMD folks and linux core folks. As I understand it amd said basically 'we're making our driver this way because you keep changing the function interface for video drivers' and the kernel folks said 'if you do that we won't accept it'. Then AMD made it their way so they could finally have a proper functioning gpu driver on linux while not sinking a ridiculous amount of money into a platform that such a small number of people use. Then the kernel folks said 'nopenopenopenope' and rejected it. And then I lol'd.

I dont care how many symbol varieties you have, I personally have difficulty reading a 2d graph with more than a few (for the purposes of your graph, lets say 4) groups of data on it. I mean I know its necessary sometimes to show more, but in your case, what is the user of the graph going to look at? Do they really care about all of those variables at the same time, or as mentioned could you divide it into 1 graph per material, or 1 graph per particle number. If you do need to show all the data at once, one of the graphs in this package may help: http://advancedplotting.github.io/ It uses the python matplotlib library which is intended as a clone of matlab's plots which are better than labview's really nothing special compared to the glory of the labview graph control, down with matlab. Some (different) people have used mscharts with some success but I've never personally looked into it.

I've done this several times in recent memory: -Writing to a file with a timestamp in the header, if input timestamp is not wired use current time else use wired timestamp. -I made a little cluster unbundler helper function. I have a cluster of basically hardware resources and then each hardware resource has a 'measurement' associated with it. If you leave the measurement selection unwired it returns all measurements from all hardware, if you wire up N it returns measurement N, if it exists, from all hardware. -Made a function which returns a set of strings, for example, then later added a filtering feature. If I implemented the filtering feature straight I'd have to require that the filter array always has .* by default. So if that particular field is empty, I treat it as the old unfiltered function and if that array of filters is not empty I do the new pattern match feature. Obviously all of the above work just fine, but there are occasional hoops you have to jump through (for case two for example I have to build what I know to be a single element into an array so the loop concatenating output will not be mad at me). Its also difficult to indicate in a very obvious way to the consumer of such a function that the behavior is as stated, unless you encode a long description into the terminal name.

He did the same thing with a DVR in the zeromq code, I wonder if there isn't a different reason here (or maybe he came up with the DVR idea later).

The wrapper also ensures that if you hit abort, any open files are closed automatically through the callback system. How would you accomplish that without some middle layer?

In linux, macs and 2016+ windows you can only have 1024 connections, but I believe this includes any in the time_wait state. If your server side is the one closing connections maybe you're running out of sockets to talk on? Also, at least on windows you can get access to the underlying socket using http://digital.ni.com/public.nsf/allkb/7EFCA5D83B59DFDC86256D60007F5839 You could potentially add keepalives at the socket level rather than implementing yourself (its just an input to setsockopt and the windows equivalent).

http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/flattened_data/ it just means " Flattening data makes the data from an arbitrarily complex cluster contiguous rather than stored in several places. "

You could also return an error 43! The way I see it is that (a) positive logic is good and (b) there is only ever 1 good path (user enters values and presses OK) and depending on your dialog 1->N bad paths (cancel, hitting close, the dialog talks to something else and actually genuinely had an error, etc).*

this definitely sounds like the easiest route assuming you never need to call a child directly. Its worth mentioning that I've had issues with updating PPLs in the way you intend with regards to classes. This was in 2013 and they've done a ton of work on ppls since then, but I'd strongly suggest doing a proof of concept where you make a few minor changes to your parent classes without recompiling the exe or other ppls. That is, exe v1.0, childclass.lvlibp v1.0, parentclass.lvlibp v1.1. I found that very often I had to recompile both the parent and children for it to work, which is obviously less than ideal. I hope this has been resolved.

I would guess you can't. If I'm not mistaken max and labview are very particular about what they discover. If you look at release notes you'll sometimes see that max/lv get driver support for hardware several months before release. If you look at the last section here (http://digital.ni.com/public.nsf/allkb/2DED4C9DA08F627B86257F9A00579B05?OpenDocument) you can also see that it specifically says "LabVIEW Communications 2.0 System Designer can now detect your system." If you see the description here (http://www.ni.com/documentation/en/labview-comms/latest/rt-targets/registering-real-time-system/) it sounds like this hardware view is in place of max, not in addition to. Just skimming the files it seems like the image in that ISO includes a full software set -- I can't find any document which describes installing software to an RT target, which is kind of a conspicuous thing to leave out of documentation which is otherwise fairly complete.

It sounds like you've dropped VIs down on your block diagram and the compiler is statically linking everything. To be able to load from a dynamic library path you'd need to use VI server to get references to the functions you want to call. This palette lets you find a lvlibp and get exported functions: https://zone.ni.com/reference/en-XX/help/371361N-01/glang/packed_library_palette/ One thing that may work, as horrifying as it sounds: You could load your main code dynamically using VI server and before doing that, use VI server to dynamically load the packed project library and all exported functions at the new path. Because you've manually loaded them into memory, when vi server tries to load your main function it should find the copies of the lvlibp already in memory and say "oh sweet I don't need to load this". Or, because lvlibps are half-baked it may just collapse in on itself in a black hole of misery. One or the other. And of course the best question is why you want to do this. Whats your use case?

this might be sufficient?

The design of distributing code components among numerous self-contained processes is already geared towards the goal of modularity and scalability. Depending on how responsibilities are separated, these different processes could scale out (I need to handle 8 new devices so I launch 8 new loops) or provide modularity (one of my devices changed over from a Tek to an agilent so I just need to swap out this one process). These benefits are similar to those of the more common synchronous OO code and both styles are related to https://en.wikipedia.org/wiki/Message_passing (see especially "synchronous vs asynchronous message passing"). What you're saying is that you want to layer the synchronous style of OO on top of what is (or is close enough to) the asynchronous style of OO. This is why I ask...what specific things do you want to do with LVOOP that you can't currently do with your existing design. The answer to that should give you an idea of how much LVOOP you might want to use to accomplish those goals. To try to give an example rather than talking vaguely, actor framework has a few different goals and layers. (I am not the expert on it so I'd refer you to this document for a more official view.) -It provides an interface for dynamically launching processes. In order for this to be generic, the developers went with an OO solution. -It provides a mechanism for handling messages generically where each message is bound to a particular hierarchy of processes (eg mymessage might perform actions on myclass, myinstrmessage might perform actions on myinstrprocess, etc). Actor framework combines the two but it sounds like you only want the second bullet -- unfortunately, this is where most of the class implementations are. I mentioned half-way routes...one *example* is that you could implement something like this: have a class called "myStateInfo" and it has a "handleMessage" dynamic dispatch method which takes a string and a variant. In the "handleMessage" method, you have a case structure based on the string, and you use that string to perform whatever actions you'd like. In the "default" case, you call the parent method. This would give you some measure of reuse (you don't have to implement a message handler that your parent already implemented) but would only require 1 class per process.

It sounds like your plan would be to follow the actor framework approach, where each receiver is a class (7 module+1 main) and every message is a class (+100-200). Its definitely been done, and its a concept that NI supports given that actor framework ships in the product, but I personally wouldn't want to deal with that many classes in a project. Labview becomes significantly more unstable just by adding a single class, and both stability and (edit time) performance take a hit as you add more. There are alternative half-way routes too...what benefits do you expect from OOP for your application?

How is this for a confidence boost: remember that there is a good chance the folks interviewing you are not particularly good with labview. Might sound silly, but if you're not going to an alliance partner or interviewing with any of the people who post here its likely that the organization's user base for labview is some folks who found it useful for accomplishing their work. Even if the company has a dedicated labview team, you're still likely to be interviewed by folks in different areas of the company and some of them will not know labview, so wowing them with labview skills...is meaningless. Along those lines, I think its better to focus on what you have done to meet the goals of your current organization...with some little bit of focus on how you used labview to accomplish those goals. If you are like me, nobody you're doing work for cares whether or not you use labview. They care if the data gets acquired reliably and they care that the system doesn't break, but could not care less about the tool used to do this. So, to me, your concern/confidence should be centered around "can I do the sort of work they expect from me, or can I learn in a reasonable time frame" rather than "am I good enough at labview". Bonus confidence boost: if you believe folks on the internet, the hiring process for most software jobs is terrible and broken so it likely doesn't matter how good you are

Sounds like it would be easier to script the behavior you want http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/enabling_vi_scripting/ an example for the 2015 pop-up menu feature: http://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Add-SubVI-Description-llb/ta-p/3524700

The instructions are under the FAQ link I posted on the last page. The URL changed to: http://forums.ni.com/t5/LabVIEW-Channel-Wires/Getting-Started-With-Channel-Wires/gpm-p/3505658 ps. man this community upgrade is so great, right? If you get the "message not found" error it really means "log in" and if you still get it, apparently the migration made the channel group private so go up one level and join the group.

If high performance isn't a requirement, you could install wget or curl and use the system exec function to call it. If you do need performance, you could technically develop a wrapper for libcurl, but it may be more trouble than its worth. Of course, for some reason I think I read somewhere that the labview functions used curl in some way (in which case why would XP be different?), but that could be totally made up.

you can also convert to a png or other format using imaq write string and then parse the string in c#.

I had both cases in my post originally but removed the labels to try to make it more clear The behavior is identical for reentrant and non-reentrant.

My guess would be 2040-1904 ~= 2^32 seconds. The labview timestamp is supposedly an I64 but maybe that function (since its ancient?) is 32-bit. I would bet it uses these guys: https://zone.ni.com/reference/en-XX/help/371361J-01/lvexcode/datecstring/ https://zone.ni.com/reference/en-XX/help/371361J-01/lvexcode/timecstring/ Definitely not what I would expect.

I'm just trying to show that the VI profiler says the dynamic dispatch calls are call-by-ref instances. The code shown is all the code being run through the profiler ('untitled 2' being top level). I don't know if the vi profiler is telling the truth, but thats why I thought DD ~= callbyref.

I have no real idea how it works, but if you make two boolean channels for example they both point to the same VI in the channel instances folder on disk. Since the data is a functional global, the compiler must by some magic figure out which FGV is associated with each channel. I would assume it uses call-by-ref or something similar to figure out how to assign a specific channel instance to a given call site, but I'd certainly be curious if there were a real answer to this somewhere. I (well mostly other people I work with, but hey) have done a series of benchmarks which show to my satisfaction that DD is on the same order of magnitude performance as call-by-ref. I'm not sure what difference in performance you saw. The reason I accuse DD of being similar to call by ref is that this is what I see in the profile tool. It shows every DD call site as being a separate call by ref instance: Block diagram of untitled 2.vi, calling 2 instances of DD function untitled 1.vi.

I don't know how much this got optimized before 2016, but if you look here at the 'what goes on behind the scenes' section: https://decibel.ni.com/content/docs/DOC-41918 "the channel wire is replaced by a static VI reference to a clone VI that both writers and readers share....Some of the implementations use the core VI for their entire implementation. Take a look at the Pipe template for an example of one of these." Unless anything has changed in the last few years, VI reference calls are obscenely slow. If you've ever poked around the "why is lvoop so slow" threads, the answer is "lvoop isn't slow........its just the technology they're using" (which is VI ref calls). Other thoughts: -Re the global, they are fast but I don't think they're that fast...60x faster than a dvr accessed by a single thread seems awfully high. -You missed RT FIFOs in your benchmark, should be on par with queues. -As mentioned in the link, channels have other more performant implementations -There is a use case for out-of-band stops, but its generally better to use in-band (user event for an event loop, a 'stop' message for queued message handlers). One nice thing channels do is they have an inline stop bit, so consumers can be told "this is my last bit of data, you can stop after you're done processing it".

I dunno if you saw this, but if you move sub2 into the 2nd loop it actually does the right thing. Also, if you return to the original state and put a breakpt in sub2 (like just wire it to a case structure) then both loops will start but you hit the breakpoint after stopping loop 1 but while loop 2 is still running (ie putting code in sub2 doesn't fix the issue, but moving the basically code-free sub2 into the loop fixes it). Kind of concerning since I've seen people do this for dialogs (I confirmed it also fails for event structures).