Labview Core 1 Pdf

[Marketta Filipovich]

Igreatly appreciate the on-line courses Core 1, 2 and 3. I have been programming on and off with LabView for about 15 years so my knowledge is spotty and never complete so that is why I may go though one core path then switch to another path. Currently I am going through Core 1 on my home computer but had to switch to Core 2 for some information for a project I am working on for my employer. I was also trying to do some of the Core 1 lessons on my work computer (different email) and that is when I started having trouble with the Learner Dashboard. It erased my progress with core 1 and core 2 like I had not even started or completed anything. A similar thing occurred when I was following the legacy learning tracks such as Core 2(2015) and others in the past. I can re-open the courses but it is like I am starting all over. Is there something I might of done or a reason for your system to delete all of the progress on my account?

I have been using the same account to log in but I was wondering if the access of it is limited to one email address. My company paid for a single LabVIEW Base Development license so the courses are through that. My home email ( pau...@comcast.net ) has been associated with LV licenses in the past, one under my own name and the other with FIRST robotics competition. Could that of cleared my history?

What would be REAL nice would be if we could use them just like regular controls. That is, you just place it from the controls palette, just a regular terminal on the block diagram that you use like any other, and (most importantly) they behave as expected inside clusters and arrays. Just like with regular controls, you don't need a reference to the control for basic read/write functionality; if you want to do something more advanced that requires a reference, you can use the VI Server Reference node. Maybe even have the reference wires automatically (or through To More Generic Class) coerce to the refnum type of the control it's based on without anything extra.

Basically, if this is implemented the way I hope it is, using a QControl would be no different from using any other control. And of course, the current way of using them would still work, for backward compatibility.

I just started down the rabbit hole of making a new XControl recently. Oh man such a pain. Here is a little graph I made complaining about the XControl creation process, and the time needed to make something useful. Any alternative is appreciated.

In end effect what we need is the ability to actually inherit from existing controls in order to extend their functionality. Just being able to extend a String control to allow for a dictionary should be possible without it being distinguishable from a "normal" String control on the FP or BD (Perhaps for some identification on the BD of it being an extended control).

You are incorrect they do and it is amazing. Here is a slider that I made into a QControl and I have all the normal slider stuff, but then have the extra stuff I added. It isn't perfect, like you can see the "Scale" normally opens up another submenu but in this case it just returns a reference, but with this you can then do the same stuff. Or you can just reference the original control instead of this class and do things exactly like you always have but you won't have the new items.

I think rather than thinking as it being an alternative. Think of it as a run-time only package. There are no edit time capabilities and it isn't encapsulated like an xcontrol. It would have been useful for my Markup String xControl if a little unweildy for the end user (they would have had to have init and deinit Vis and an event structure instead of just placing a control). But It wouldn't have been much use for my Tab Control as that needs edit time capabilities and doesn't inherit from any existing control.

I've done something very similar, I'm aware of the benefits and the limitations of this type of implementation. Code changing properties of the control in parallel to the LVOOP approach can be very hard to manage.

Oh. On this point. I'm currently struggling with the "dirty vi" propblem. If I set the state to changed, the VI it's used in wants to be saved (even though nothing has changed). If I don't set the state, the control won't update the facade.I can live withthe dirty VI but "Level where general public would find it useful" is just out of reach.

NI should be working on a proper implementation of extendable controls (C# inheritance was touted, then it turned out that will be limited / useless). I fear they are looking for a way out of that corner. But still, if we're realistic, there'll probably be notnhing of that sort coming in the next X years, so this IS a boon. I just hope this doesn't stop NI working on a proper implementation.

I'm not casting any shade ont eh toolkit itself, it looks pretty amazing. The reason I think it might sway people at NI is because it IS good. If it would be half-arsed, I wouldn't be afraid. So from that point of view, technically speaking, ?

Okay to be fair, QControls don't actually extend the VI Server tree, but from a developers perspective the outcome is the same, or close enough to not matter. You drop a property node, and you get get access to all the same things you're used to, and the new things. It looks like a duck, but might not be a duck. I can see why code changes in one place effecting the other can be weird, and for that I can think of a few ideas that are probably terrible. I haven't used them extensively yet, just working on a few ideas, but since it solves so many of my XControl problems, and adds just a couple problems of its self, I'm okay with it.

Well. NI have never really worried about finding a way out of a corner - I'm still waiting for unicode support but I take your point. If NI see this as fullfilment of an issue, the 11 xControl bugs currently in the known bugs list will never be fixed.

Yeah but I want the best of both worlds, extending existing controls while also being able to use it via just a block diagram terminal. Also I'd like something I can put in an array or cluster; XControls can't do that and I don't think QControls can either.

I've actually been meaning to see if I can figure that out, lol. I already know how you would load a control from a DLL: there's a hidden "Plug-In Control" object that, when placed via scripting or a modified palette, allows you to load a DLL from the context menu. You can place it via my Place by Style Quick Drop plugin. Incidentally an uninitialized plug-in control is the only way I know of to get a control with "void" as its type. (And I don't mean empty clusters or void arrays.)

You are right QControls do not inherently have edit time behavior but I see the edit time behavior as one of the problems XControls had. It made them difficult to work with and took a lot of programming just to get the basics.

I don't think XNodes would help with this. XNodes are great for making a single thing on the block diagram do different things and encapsulate functionality in it. But there is no front panel connection with an XNode. The best you could do is maybe make an XNode, that internally links to a control reference on the FP. You'd still have the normal control terminal on the block diagram because I don't know of a way to make the control terminal itself invisible. If I could then then that would be a solution, but likely full of hacks and who knows if it actually would work well. And then you'd be dealing with a technology NI isn't interested in making more public. If QControls did have an XNode component, and it could essentially replace the native terminals and references, then I'd suspect NI would be less interested in making it part of the LabVIEW core. One nice thing about QControls today is how it is normal pure G, which as you mentioned might be why it has a hope for being ported to NXG.

With xControls, everything takes a lot of programming to get the basics, hence why your toolkit has a place (which it excels at, by the way). But once you have the basics of updating/drawing/refreshing the display (the hardest part), creating edit-time functionality isn't difficult. - mainly menu manipulation. In fact. Because front panel menus are mainly used to configure a control at edit-time and you can add in-built menu options to a custom menu; inheriting functionality from the architypical control (like enable/disabled/greyed out) isn't a problem and doesn't have to be re-implemented as it does with the diagram properties and methods.

I work in a test and measurement lab and we use LabVIEW to automate our testing (RF, EMI/EMC). We currently have some labVIEW programs up but no one to maintain/upgrade or design new processes and I am planning to step into this role. Is it feasible to expect to jump right in after the training?

It will not provide mastery of best methods and practices with a thourough knowledge of the intracacies of programming in LabVIEW for yor companies needs. BUT, you found the forums.....come back often! You'll learn more here by accident than you might imagine!

3a8082e126