Stagg54

On ‎6‎/‎16‎/‎2017 at 7:10 AM, hooovahh said:

I worked at a company that had all USB devices disabled.  Not just USB memory devices, but also USB CAN, USB DAQ, USB Serial, USB GPIB, everything.  For the DAQ stuff we would just simulate the hardware, then deploy it to test it.  It was a pain but not too bad.  The USB memory devices were easy to get around.  It made the USB stick read-only, so to write to it you would map some empty folder like C:\USB to the E:\ drive or where ever your USB was.  Then you could read and write to the C:\USB folder all you wanted which actually wrote to the USB device.  I guess they just setup software to disable writing to drives that were marked as removable. 

That DgAgent sounds nasty.

We got a new head IT security guy.  Shortly after starting, he somehow got a virus on his laptop from a thumb drive he picked up somewhere. The solution was to ban thumbdrives.  So he sent out an email to the entire company that said basically: "Due to security risks, we are banning all USB thumbdrives except for these special ones that are encrypted and have fingerprint readers built into them.  They cost $200 (for a 4 GB drive).  Oh and they are backordered and won't be available for 6 months.  If you want one, let us know and we will put you on the waitlist."  It was almost universally ignored...

I wrote software that was able to run in nuclear power plants, but was apparently not trustworthy enough to have administrator access on my own laptop.  They had no problem giving me administrator access on the machines that the end software got installed on. So I could run the installer on the actual machine, but couldn't test the installer on my own laptop.  Seemed kind of schizophrenic to me.  One hand they trusted me, and yet on the other hand they didn't.

I also worked in an R&D lab where we were constantly evaluating new hardware, which of course involved installing drivers. I would have to put in a ticket and have the local IT guy install it for me. After several hours he would walk over.  He had no clue what I was installing and didn't really seem to care much either. I would just start the installer and when it asked for admin credentials, he would come over eventually and put his in.  Then he would walk away.  

Is there a way to use vi server to communicate across the app instance boundaries to achieve what you want?  Seems like that might be doable.

Looks like you are doing sequencing.  Instead of reinventing the wheel, perhaps consider using Teststand...

They could also be worried about this:

https://www.usbkill.com/

Dynamic Dispatch is your friend.

It sounds like you are on the right track, but you just haven't had that epiphany moment yet.  It will come.  Try and find some example code to look at.  I'm sure there's plenty out there (just don't know where off the top of my head).

Yes, that is what I do. I currently un/flatten the class to/from disk in much the same way Michael describes (I actually developed the technique from copying stuff in an article Jim posted on thinkinging?) to solve the issue you present.

Also, on the darkside Dave/Jack/AQ instigated a great discussion on such issues with this - well worth a read. In summary, blindly trusting NI's implementation is not advised for mission critical stuff but it is the easiest way - but won't fix your issue methinks.

Do you happen to have a link to that article?

Title says it all. 

I'm a CLA (been one for over 4 years now) and I'm thinking of moving to Denver and looking for a job out there. 

It might be kind of clunky but in this particular case you could convert the I32 to a double and append to either the front or back of the array (so you would just be sending a fixed size array of doubles) and then remove it on the other end.

It you only want to change what is displayed on the graph do the following:1. Right click on the x axis -> Deselect autoscale X2. Highlight the leftmost value on the x axis (in this case 0) and you should be able to change it to whatever you want. You can do the same thing for the leftmost value.If you want to actually remove the samples from the signal and then do some calculations, then it is more complicated.

However in both caes it's illegal to open the lock with anything else than the key.

 

Ton

Yes and No.

Consider the case where I lock my bike up and lose the key. It's not illegal for me to break the lock and take my bike back.

Context Help: It is probably just me, but I find that a bit klunky for an application. Works well for the BD, but it is growing,shrinking and otherwise distracting. It is easy to learn to love it when you are the developer in charge of reinventing that wheel, but users who do not know or care about the trouble involved may not like it. (Caveat, I am too spoiled by what I can do in other application frameworks, things like balloon popups with html formatting).

Maybe it would be worth writing an xcontrol with a string indicator and have the xcontrol monitor the parent vi (not sure if that is the right terminology) and whenever the user hovers over a control, the xcontrol would display the help description of the control (that is being hovered over). It seems like you ought to be able to do that.

Although that seems like a lot of work.

Also the other way that context help breaks down is with subpanels. When you hover over a control inside the subpanel, LV only displays the context help for the subpanel itself, not for the control within the subpanel vi that you are hovering over. Hope that description makes sense. What I've done to compensate is just write a simple vi that runs in parallel and knows what vi is loaded and has a reference to the subpanel control and then whenever you hover over a control in that vi (detected using dynamic events), it updates the description (and possibly caption) of the subpanel control (using VI server), effectively "fooling" LV. LV is still displaying the description (and caption) for the subpanel control, the description is just changing on the fly to match which control the user is hovering over.

Hope that all makes sense. That seems to work for us.

Typically we just use the context help. If you enter a description for a control/indicator, that will show up in the context help window. You can programmatically show/hide that. So you just have a help button that pops it up. Then when they hover over a control/indicator the description shows up in the context help window.

If you do make XControls, you could probably have the it initiate a separate process when it's dropped which will receive the references to the dropped controls. The process will then delete the XCtls (or it could possibly be a single XCtrl and it will replace it with two clusters), replace them with error clusters, wire them and then terminate. I don't know if this has any potential pitfalls, but it seems like it should be doable.

When i first read your post I immediately had the same idea. Yair beat me to it.

I agree with Jack.

I think it is a feature that should not have been implemented. From the point of human performance and error prevention it is horrible.

Why not just have a seperate TCP/IP process (call it a moderator) running as a seperate app? Have all your logic in there.

When each of your seperate apps startsup they checking to see if the moderator is running (by attempting to open a connection to it). If not, then it can spin one off.

If you have that many instances of this behavior it would be worth your time to create an Xcontrol.

Second this idea. You could definitely make an xcontrol do what you want. Xcontrols are usually a pain, but if you've got that many of them... The first thing I would ask myself is how important is this "feature"? My inclination would be for the end user to just deal with it and ok maybe it's not that intuitive, but it's a lot easier than writing an xcontrol. Then again if they want it bad enough and are willing to pay for it...

There are nodes that let you drop Matlab code directly into LabVIEW (with a limited function set). However I believe they require more than the trial version of LV (not sure what version you need - check the NI website). Note this also requires a Matlab license which I am assuming you already have.

It's a shame that the conditional disable structure cannot tell what version of LabVIEW it is. I've got a "Tick Count" vi that uses the perf counter method on windows, the normal (1ms) one on the others and it would be great if I could put another case in there to use this little gem for when I'm working in 2010 and greater so it uses the best available (I have to work in 2009,10 and 11).

Sounds like something for the idea exchange.

to add to Rolf's post:

for an abortable wait loop, I just use a notifier as the loop timer. I set the timeout so that it will time out at the correct point in time. Then I can abort it early by sending a notification.

I'm sure other people have other ways of doing this, but I've found it works for me and seems fairly clean to me. YMMV

Perhaps I should have explained more, but I figured if someone had to ask what the heap peak window was, then they wouldn't know the answer to my question.

I'm trying to use the Heap Peak to get rid of some insane objects. However I am having problems with the F button. I've highlighted the appropriate entry in the right window, but for some reason clicking the F button does nothing. Now this vi has several tabs. It is possible its on a hidden tab and that's why it is not showing up?

Anyone have any experience with this?

I am using 2011 SP1 F1 if that helps.

I should have read Darren's article first, because that is exactly what he suggested.

My suggestion is similar to Tons. I just use an array of cluster, where each cluster contains just an array.

Just took the CLA-R last week and I can tell you definitely want to at least read the book and take the practice exam before you take the CLA-R. I'm sure its possible to pass without doing that, but it would be very difficult.