ShaunR

Heathen

Yes. It is in the build process, not at install-by then it's too late (at install) and the recompile passes but the VIs are broken. By the way. this happens also with the TPLAT so it isn't a particular VIPM problem. The work around is to delete the DLLs just before building (so that VIPM or TPLAT fail to find the files during the build) and press "ignore" when it searches. Luckily, that doesn't fail the build but I can see that at some point they might "fix" it so the build fails.

I was going to be flippant and say "The NI forum has loads" but they don't work either.

Don't you use a modified OpenGPackage Manager for zlib rather than VIPM? I'm not sure if it is the same issue but when VIPM compiles the *.* it "fixes" the file path to whatever bitness you compiled it in if it successfully finds the library. That means if you created the package with 64 bit LabVIEW and the file name is "something_*.*", then the path gets "fixed" to "something_64.dll". The result is that something_32.dll isn't searched for when installed and recompiled on a 32 bit platform and the Vis are broken.

Code Library Function Node. The prototype you have put on the diagram. It is the "Return Value", the first and fixed item in the parameter list. Set that to Numeric and then choose Signed 32 bit Integer. You can't with that function. It requires a lot of setup allocations before you can call it. You need to start with the initialisation and de-initialisation functions then build it up from there. I would suggest using the DLL import wizard as a first pass (in the LV menu under Import>Shared Library(dll) ). It will create the VIs with the nodes (where it can) and then you need to figure out what it got wrong and what order to call them in. I would guess nxDrvInit and nxDrvExit are the first calls you should be looking to try.

Your basic goal is to get the function prototype (shown at the bottom of the CLFN dialogue) the same as that in the documentation. You have void xChannelIORead(uint32_t ulAreaNumber, uint32_t ulOffset, uint32_t ulDataLen, InstanceDataPtr *pvData, uint32_t ulTimeout); The return value is int32_t not void. You are missing the Handle parameter (CIFXHANDLE) and pvData is a pointer to something (probably an array) - not an InstanceDataPtr (which is a special LabVIEW parameter). Even if you fix that. You are still not finished. You will need to call other functions to get CIFXHANDLE through some sort of initialisation procedure and then deinitialise once finished. You will probably also have to call the enumerate functions to get the boards and their channel numbers so you can populate those parameters. If they have provided C/C++ examples then that will tell you what functions you have to call and in what order. Any mistakes will usually result in a LabVIEW crash. For the calling convention, you will have to look at the header files.

You mean it's "dark"? 😋 You can already do similar stuff like that with LabVIEW (although it could be a lot easier). What you can't really do is skinning.

Hmm. I'm not sure what your expecting me to say here. For debugging I want to see the results (on the FP) whilst I go probing the diagram (or even sub diagrams) especially for intermittent bugs. Quite often I throw indicators up instead of using the probe window, which I've always detested as it gets in the way of everything and you can't resize controls. So the FP becomes my probe window (usually after I found the place with the probe window). I tend to make changes to the diagram then hit CTRL+R in a kind of micro test when I'm just tidying up so I make sure I get the same result on the FP after rewiring - I don't want to keep moving windows around between editing and viewing the result. So I have all FPs are on the left screen and all diagrams are on the right screen.

When I'm working with dual monitors, I usually have the diagram on one and the FP on another - lots of room to work and uncluttered. Even when I'm working on a single monitor, I usually have multiple virtual desktops, again with FP in one and diagram in another. You can kiss that workflow goodbye with MDI.

I've said it before and I'll say it again. Speed of laying down primitives/controls is a non sequitur. It even pales in comparison to the time spent making sure wires were straight and non-overlapping (which I find oddly relaxing). I estimate that as little as 10% of my programming time is actually placing VIs, controls, primitives et. al. 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. I'm banking on that by the time they get anywhere near parity with the proper LabVIEW, I will have retired and won't have to use it.

They didn't need to do that. All they had to do was enable the rendering of UTF8 strings and we could support unicode easily.

Meh. Had that for years

Is not? Or do you mean is.

1. It is a call parent method. 2. Placing the Call Parent Method (located in the cluster, class & variants palette) will adopt the parents method if the criteria in the aforementioned document is satisfied.

I've resolved the issue. Zlib Library for LabVIEW (BSD-3)

Take a look at the "Align and Subtract" example in the example finder under resampling.

Prepend the packet size to each message in your python script then you can use the following method which is the most efficient Watch out for the endianness of the size bytes. LabVIEW is big endian (or network byte order). Once you do this you can get fancy later by adding timestamps and whatnot, if you want, since you effectively just using a custom packet header.. Next. find out about the Nagle Algorythm settings on the RPi. I think on Windows the default window is 8K bytes but I have no idea for RPi what it is set to. This will limit transmitting to be either sent immediately (if greater than the buffer) or after N millisecs if less. (Again, windows is default to 250ms). Decide if you need to turn it off to achieve what you need. Note that this only affects the server side. You haven't said how you are connecting (wired ethernet or Wifi). Wired ethernet is far superior for high speed acquisition than Wifi. wired ethernet will easilyget you up to 80% of the the bandwidth available - Wifi you'll be lucky to get 50%.

I hate Win 10 just for making me chase tiles around the start menu for 10 minutes trying to get them into menu folders.?

Ask them about BridgeVIEW

Lava serves this purpose well. In fact. my last interaction with openG was here

Of course not. But some of the toolkits haven't been updated for a few years because of the reasons I stated. So it's an example of why the trope about no development activity is untrue. This is why I don't put dates on the public version history. By the way. The idea that development activity is a sign of a "live" project only came about in recent history once people got used to buggy code and alpha releases purporting to be a release proper. I view continuous updates and lots of activity as unstable and therefore unusable code. If one is contemplating using a library or piece of software and think it is less a project risk if there is lots of activity, then, IMO, one has admitted that ones own software will be unstable and bug ridden. I don't exactly know at what point alpha software was accepted as the the norm for final product but it seemed proliferate in the switch to Agile Development.

That's a trope initially perpetuated by marketing people. There is no message. If developers discontinue a product they will [almost] always say so in the notes, comments or website unless they were unexpectedly hit by a bus. I have a similar problem with this perception. Many of my toolkits are feature complete at initial release. There is usually a period of bug fixes shortly after release and then no updates because there are no new features and no reported bugs.

No library is dead whilst at least one person is using it.

I a similar vein. The toolkit gives new starters a lot of examples on how to use prototypes in LabVIEW - in small, easily digestible chunks IMO it has enormous value as a teaching resource and as an exemplar of coding style.

Yeah. I can't claim that one. It was originally a criticism of OOP