ShaunR

Put the 3 sec delay after you set to top

Doesn't the Vision Assistant or vision Builder have the ability to show diagrams? I have a vague recollection of someone using the same technique in their application (something to do with subpanels?) On the other hand. Maybe I just dreamt it

Then how does this work in multiple browser windows? You can run it yourself (as a built application) by downloading from the link in my signature. Or even play with Dispatcher in th Code repository and buld an exe out of it.

Now I know what a "lac" is. No. You need a proper database.

Yes. you can have multiple services. but you can only have one listener. You need a connection handler to offload the endpoints and I guess the NI webserver doesn't do that (never used it, so don't know for sure). It is, however, trivial to write your own.

Using a man-in-the-middle attack for convenience is a flawed concept.

Well. When I logged into my bank account the other day I was met with this message Do we believe them?

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 .

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 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?

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

Ah. Here Rolf and I are in total agreement.. CINS are to CLFNs as MP3s are to gramophone records. 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: I think I even gave you a 64 bit version of zlib at one point (with minizip) I'm about you make you eat those words Slightly off topic. But does VxWorks come with libssl?

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.

Another things which wasn't touched on in the video. Sometimes you have to interact with hardware with a technician/engineer present. Especially when going through wiring, schematics and generally troubleshooting which is invariably in an industrial situation-in situe. Describing what they can see is very difficult especially with a language barrier and for them to carry a laptop around and use it to send images/video of exactly what they are seeing isn't very practical. A head-mounted bluetooth video camera is fantastic for this and very convenient for them. They just need to pair it with their phone and you can see what they can. If you have ever had to remotely troubleshoot wiring it makes it sooooo much easier discussing wire idents and spotting that clue that tips you off to the solution.

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)

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..

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.

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

The NSA have to use other methods to tell you are connected Good catch and thanks for sharing.

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.

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.