ShaunR

It's a good thing NI never got around to making an SSH toolkit

OpenSSH is a different toolkit and, although it does use OpenSSL, the vulnerability only affects TLS (which OpenSSH doesn't use). OpenSSH is quite safe,but if you are using a TLS enabled process (like Apache) that has the heartbeat extension (i.e TLS 1.2) then they may get your SSH keys, your inside leg measurement and who you slept with last night .

So, most of you here are probably aware of the Heartbleed bug in OpenSSL.

 

How seriously is everybody taking this? Seems like a good time to change my password; "12345" was probably due for an extra digit on the end by now ;-)

Very seriously 

It is the only time I've ever heard that using encryption is worse than not using it.

Luckily, the binaries shipped with LabVIEW are not susceptible-they're too old

I haven't dealt with your specific issue as I have never implemented virtual tables (I tend just to modify the query).

However. You can inject an event sender into the control so you can get any controls event info regardless of focus - even on floating windows etc..

You are forcing LabVIEW to interpret a 2D array as a string. It isn't. It's a 2D array and because you are unflattening, you are getting ll the array index info in the string..

Use the index array to obtain a single element from the array returned by the SELECT function. Then use the Variant to Data primitive to convert it to a string.

Unflattening requires that the data was stored as flattened to begin with. I expect it wasn't.

I heard recently that when you look at your code from 3 years ago that you should feel disgusted.  If you look at your code and think you did a pretty good job, then you aren't improving, or using the new techniques and features in newer versions.

 

Isn't it quite interesting how LabVIEW code looks dated?  I mean I can look at a block diagram and and based on coding styles make a pretty good guess at what version it was developed in.  Oh using white labels instead of transparent on block diagram controls?  Labels on the left or the top of controls?  Comments not part of the wires but intended to be?  Bookmarks?  Subdiagrams on structures?  Lots of polling controls?  Default subVI icons?

 

When I look at C++ code from 5 years ago it more or less looks the same.  But 5 year old LabVIEW code is very different.  Either we're changing too much, or they aren't changing enough.

I look at my code a week later and feel disgusted Since I still use 2009 (through preference) my coding still looks the same as it always has. My VI Icons are better now though. Does that count?  

vxWorks doesn't come with openSSL out of the box but several NI tools such as the webserver will install an openSSL library (that NI supposedly cross compiled for this purpose).

Sweet.I'll test it out on a sbRIO at the weekend once I can remember where I "stored" it

Next item on my reading list: anything I can find about cintools starting here.

Ah. Here Rolf and I are in total agreement.. CINS are to CLFNs as MP3s are to gramophone records.

We agree to disagree here!

I find maintaining platform discrepancies and low level pointer acrobatics on LabVIEW diagram level simply a pain in the a$$ and a few other places too at the same time. It's much easier to maintain these things on C source level and allows easy adaption in a generic way so that the LabVIEW part can concentrate on doing what it is best in and the C part too.

I know that the lvZIP is not an ideal example since the 64 bit support is still not released but basically supporting 64 bit there if everything had been done on LabVIEW level itself would be a complete nightmare, now it is basically working out one kink in the cable to allow private refnums to work for 64 bit pointers too. There are two solutions for that, using an undocumented LabVIEW feature that exists since at least LabVIEW 7.0 or cooking up something myself to translate between 64 bit pointers and LabVIEW 32 bit refnums.

The real reason that lvZIP still isn't 64 bit however are much more profane aside from time constraints. For one I only recently got a computer with 64bit OS and for the other a change from sourceforge about maintenance of the SVN read/write access which is not natively supported by TortoiseSVN has kept me from working on this for a long time.

I know we do And my view that Linux is a community version of Windows 95 (a GUI bolted onto a CMD prompt), probably won't sit well either .

I wasn't actually referring to lvZIP. I was thinking more about SQLite - but as you bring it up; it kind of proves my point.Zlib supports 64 bit so the only reason 64 bit isn't supported in the openG tools is the wrapper.In fact. Transport.lvlib supports it. People could have just replaced the DLL if it wasn't for the wrapper

From the Zlib website:

Will zlib work on a 64-bit machine?

Yes. It has been tested on 64-bit machines, and has no dependence on any data types being limited to 32-bits in length.

I think I even gave you a 64 bit version of zlib at one point (with minizip)

But an API like OpenSSL or FFMPEG which makes use of complex parameters beyond flat clusters is IMHO simply not maintainable for the long term without C wrappers.

I'm about you make you eat those words

Slightly off topic. But does VxWorks come with libssl?

Rolf,

Thanks for your careful explanations, they are very helpful and most appreciated. For what it's worth, I agree with the LabVIEW developers for keeping the size of pointers constant over platforms.

 

I was wondering how long it would take for that suggestion to come up.

This is one of the few points where I disagree with Rolf. Maintaining a wrapper seems like a good idea to start with, but you end up replicating all the functions of the original in the wrapper or reducing the function-set available to LabVIEW. LabVIEW is cross platform already and although it takes a bit more up-front, it is much easier to encapsulate the original, extend and maintain. Once you have good LabVIEW coverage, you can just replace the DLLs . This is great if they are 3rd party supplied (and run the LabVIEW test harnesses). It also means that end-users can update them without you having to do anything. If they add a function, you only need to create the LabVIEW part and it's job-done. There are a few projects that suddenly became unusable because they stopped maintaining the wrapper (not Rolf, of course, he maintains them forever ).

Have I ever said how much I hate OpenSSL? (just a short gripe because it's doing my head in for similar reasons )

I think you're going to have problems with a camera in this setup.

You have a bar for mounting the camera, so I assume the camera will be facing the sheet and drum?

You are trying to measure the width of a reflective material (steel) with a reflective (although grubby) background.. What tends to happen here is that increasing light intensity also causes flaring on the background. The background is moving, so the the reflection is not constant and liable to change with position and dirt. So it's not just a case of saturating it with light, you have to be really pedantic with the light levels and the discolouration on the drum itself will have you pulling your hair out  (it's a line scanner, so you have no context). Once you do get it set up, you will walk in the next day and it won't work properly anymore because someone cleaned/changed the drum and the lighting require re-adjustment. Your measurement system will also deteriorate over time as the discolouration changes on the drum as you will have to effectively "tune" it for the particular environmental condition on the day..

You are much better off mounting it in the gap between rollers then the light will work well for you (no discoloured, moving or reflective,  background) and will not be at all sensitive to variation as  the focus of the lens acts as a light filter. Stuff further way will be blurred and darker and require much larger changes in your source illumination to have any effect on your image background at all and you can krank the contrast up to find the edges. You can also choose a lens that has a very short focal depth and you will be basically checking against a pitch-black background. You wouldn't even need to have a homogeneous light source, it would work and be robust with ambient light.

That's the "ideal"........

If you cannot do that, the next best thing is to point the camera from the bar to the gap. The issue here, though, is that with your current intentions, you will be a lot further away, will have overhead lights back-lighting your image and perspective distortion. To mitigate the back-lighting you can mount it similarly as you have currently, but near the top roller pointing down. Since you are using a line-scan camera, you can fairly easily compensate for the perspective distortion with very simple (and not CPU intensive) calibration, but depending on what accuracy you want to achieve, you could also get away without it.

People are still using Skype? Obviously industrial espionage not a consideration.

I use Jitsi for video conferencing. The UI looks pretty skanky (Java after all) but it works great (screen remote control included).
The next release claims it will support up to 100 remote video conferencing streams-we'll see.

You can get remote power switches for hard-booting. I've used the telephone operated one (RPS II) with great success and they can be removed after development and reused on other projects.

Oh yes. And Bluetooth stereo headsets that can connect to multiple sources (like your customer via PC and phone)

Doesn't this make debugging true memory leaks a needle in the haystack situation?

Memory leaks are caused by not closing registrations (event reg refnums) rather than user event refnums. If nothing is registered, you can generate your events 'till your hearts content and you won't leak memory.That's why you can have plugins that come in and out of memory and attach to existing events.

Besides. When I exit, I want all memory cleared up including any leaks and LabVIEW takes care of that. When the app is running, I generally want all events running too and let whatever needs them regsiter and unregister..

Thanks also, I should probably change my original post to state I am looking for the solution that requires the least amount of "coding" time but yet still performs everything in parallel.

 

I think the best answer is to create a scripting VI.  It would be nice if LabVIEW had a "close cluster of events" primitive.

The only time I ever need to do this kind of thing is when the app is exiting. Then I just don't bother and let LabVIEW clean up my mess.

Out of curiosity is this security behavior documented in whatever API you used?

It depends if they are authenticode-signed (apparently).

 I am not sure at this stage what the implication of these security changes are, but as the machine is not connected to the interent anyway I am not to worried.

The NSA have to use other methods to tell you are connected

Good catch and thanks for sharing.

After 15 years of making LV do oddball things, I'm moving on to text coding for my day job.  I may still do a bit of LV here and there, but not much anymore.

 

I hope LV can catch up in features and ecosystem to some of the languages that have surpassed it.  It's an amazing language... I just wish it were used in more places, for more things.

 

Thanks, everyone, for the insight, advice, and fun over the years.  You all have my deepest respect for the amazing things you've done for the language and the community.

 

Joe Zoller

joe at underflow_software dot_com (no spaces or underscores)

Good luck. Be sure to poke your nose in from time to time.

I find that I'm having to resort to DLLs almost all of the time nowadays because the functionality just isn't there and when that happens, you might as well write it in a text language (they usually have working examples and don't always translate well). Apart from getting  the UI advantages of modern visual languages; interfacing to  DLLs is a works or crashes the IDE kind of deal. in LabVIEW which.makes you just give up and write it in something else.

You still cannot beat LabVIEW for DAQ, Control or prototyping, but outside of that it has severe limitations for commercial applications. I understand the move but I am lucky in that it's not an either/or decision for me. I can use whatever I think is appropriate.

You are the third person in a row to tell me that.  But sometimes one must try to balance risk with the need to keep work coming in.

A second thought.

Why not just do it as a normal contractor rather than as a fixed price project. This is much safer as there is no deliverable as such. 

Perhaps Jason can confirm the algorithm. But I don't think the graph controls just decimate in the strictest sense. I think they do something like bi-linear filtering since small artifacts are not lost-as would be with pure decimation.

Long term data logging is better served by a DB IMHO. Then it's just a one line query to decimate and you can have a history as big as your disk allows with no memory impact.

You are the third person in a row to tell me that.  But sometimes one must try to balance risk with the need to keep work coming in.

The issue is this. The risk is very high that they will try and renege of the agreement-they have all but admitted that. Even if you do put a watertight clause into the contract, it is highly likely they will contest it anyway. So you will need deep pockets to defend it in court to get the money you are owed.

If it is a large corporation, they have departments dedicated to finding holes in contracts and arguing the toss of every penny. They will use it to get more concessions out of you by - nit-picking at best, by threatening at worst. The sort of corporation you want to do business with are those that only send contracts to their law dept as a last resort, not first resort. Which do you think they are?

Your first defence should you choose to work with them, is of course, the clause in the contract (choose any from the open source contracts, they all disclaim liability). This is really a management bargaining tool, however, so you can point to it and say "that's not what we agreed". If it goes further than that, then you incur huge expense so you really need a company that is prepared to take that risk in the first place and not go further. Your last defence is Limited Liability Insurance  or Professional Indemnity Insurance to stop them taking your house, car and dog if they win.

That' the risk of all consultancy work. It's just better for your health, wallet and integrity to politely decline any companies that have a history of serial disputes with consultants, Get a good lawyer

DISCLAIMER:

Not legal advice, not a lawyer, not even particularly good programmer-make of it what you will

I am in the process of formalizing a contract with a company that has been known to have had prior issues with LabVIEW developers and has adopted a tough talking somewhat litigious tone.  I am considering what wording I should put into a Software Development Contract that will protect me from any liability in the event a bug in the software should damage the clients property.  Has anyone had experience with this?  Or perhaps could suggest a contract template to start off with.

I suggest a you avoid them like the plague.

I guess I'm a little puzzled why some people see this and some people don't. What is different?

I use strict typedefs quite frequently. Quite often I place instances in class private data and constants fromt the typedefs in class methods. Note that the .ctl files for the typedefs are in separate .lvlib files.

When I need to change a typedef I open it within the project, make modifications, apply the changes, and save. I avoid things like renaming an item and inserting another item in the same step, which could obviously cause problems. As long as I am careful in this respect, I don't (or haven't yet) encountered major issues. Maybe I've just been lucky. I'm puzzled what the difference is.

I too have never experienced it. But I remember Daklu writing an example (on lavag) to prove me wrong and that it does really happen.lol Maybe the Lavag historian can find it-I cannot currently

I vaguely remember that the reason that I never see it, is because my workflow is to have all the VIs in memory.

IIRC, when you change a typedef, the VIs not in memory are not updated,(of course) and so the change is not propagated., When they are next loaded labview isn't able to resolve the discrepancy and resets them to the zero value. LabVIEW is able to resolve the difference if the new value is at the end, but not in the middle. So I think I suggested having the old-style VI Tree just so that you could force LabVIEW to load all the VIs.

Since my workflow is to produce examples that act as regression test harnesses, the examples keep all the VI hierarchy in memory so I never see it.

You haven't told the Configure Serial Port which resource to use. Right click on the top left corner terminal and create a constant. Then select your serial port from the list.

Put the serial port initialise outside the loop (and don't forget to close it when the loop stops)

You should get it working with the Serial port examples first. Then you will see how to use the VIs correctly.

Separated compiled code has been working well for our team over the last 3 years.  There are two instances where we encountered issues:

 

• Packed Project Library build corrupting the VI Object Cache
  • The VI Object cache had to be cleared after PPL builds
    

  [*]TestStand with the LabVIEW Run-Time adapter requires uni-file code if distributed as source

 

-Brian

Just to expand on lvbs points.

If you build source plugins. i.e. plugins with diagrams so they can be recompiled on the target system when invoked from an executable. Then you must turn off compiled code separation for that VI otherwise you will get the Error 59: “The source file’s compiled code has been separated, and this version of LabVIEW does not have access to separated compiled code.

And just to reiterate a point that some people often forget. The global compiled code option only applies for "New Files" so checking it won't change all the existing files to use this method. You have to go and change each VIs setting individually and recompile.

DISCLAIMER:

The above are not "issues" as such. Just additional things that you have to bear in mind when using the option and may fit into the the grannys' eggs category. 

I'm snickering over the fact that you can mark your own post as the "best answer" to your own topic.

Yes. I should do the rest of my posts (unfortunately I have only started about 3 topics ..... ever )

Just saves people reading the entire thread as it has run its course and the link contains the solution if they want to get the code..

5 BTC competition - LabVIEW app to get address from private key

 

Source

After just over a year, someone has claimed the first prize. The original proposer for the competition is in a bit of a quandary .

When the competition was set 5 btc was worth about $75. Now they are worth about $3000 The deadline was set for when 5 working solutions were submitted, however, there has been only one and the OP has now closed the contest.

Kudos to the guy who had to write native labview code to handle big numbers and eliptic curve multiplication, which is no mean feat..