User Controls as VI

[delbertson]

Hi I'm just new to Labview and have a bit of a newbie question.

I have set up and Tested a VI to control a motor via the CAN_Open protocol, and it's working fine. It's currently in a timed while loop. It has a Dial control for speed a latch button for on/off and a radio button to select it's direction of rotation. I'm my final application I'll require 3 of these motors with exactly the same controls though the Max and min speeds will be different, as will it's coms ID. I'd like to be able to just include this VI, pass it the Max and Min values etc and replicate it on my front panel and use it like a user control.

If I hide all the controls used as I/O to the VI leaving only the user controls, and make the VI reentrant.... I can get more than one instance of my VI to run in separate windows... but I'd prefer to have them on a single user interface.

Is this possible and if so could any of you Labview experts point me in the right direction or to a url with an example of this type of thing?

Thanks in Advance.

Derek

[EJW]

... but I'd prefer to have them on a single user interface.

If you want to use a control that has a front panel multiple times within one vi, the only way i know of is to use the subpanel control. This is accessed from the front panel controls- modern - containers - subpanel. This allows you to show multiple vi front panels. You need one subpanel for each instance.

Otherwise, the ideal thing to do, would be to create your front panel controls on one vi and use a subvi of your timed loop multiple times on your block diagram.

[ned]

The reentrant VI solution is the right way to go, and you just need to separate the logic from the user interface. Create a custom control of a cluster containing the speed, power and direction controls and place one instance of it for each motor you want to control. Then, use a notifier to pass values from the user interface into the timed loop while the loops are running. Note the use of "Get Notifier Status" and not "Wait On Notification" in the subVI. As often happens with LabVIEW, a diagram is much clearer than an explanation, so take a look at the illustration below.

[delbertson]

Thanks guys... not really understood your reply's, as I said I'm a newbie from a C background... but you've both gave me some stuff to try so I should be able to work out it from here (famous last words)

Thank you both very much for your reply, I will let you know how I get on.

All the best

Derek

[delbertson]

Managed to get that working :thumbup:

Couldn't work out how to add a notifier out though. Ended up adding the control to the main VI then turned the section into a VI to create the interface.

Is there a more direct way of doing this?

Thanks again

Derek

[ned]

Couldn't work out how to add a notifier out though. Ended up adding the control to the main VI then turned the section into a VI to create the interface.

Is there a more direct way of doing this?

I usually create notifier controls or indicators by right-clicking on the "Notifier" terminal of any notifier function and choosing "Create -> Control". I then copy and paste the control wherever it's needed.

[Aristos Queue]

I usually create notifier controls or indicators by right-clicking on the "Notifier" terminal of any notifier function and choosing "Create -> Control". I then copy and paste the control wherever it's needed.

That's the only way to generate them. There's a lot of refnum controls that aren't in the palettes and you only get them by creating them from terminals of nodes.

[Mike Ashe]

... There's a lot of refnum controls that aren't in the palettes and you only get them by creating them from terminals of nodes.

Sounds like this might be a good candidate for an OpenG sub palette off the current Refnum palette. There should be a way to do this with scripting. Perhaps PJM's Private Class generator already has these. I'll check.

[Jeffrey Habets]

Sounds like this might be a good candidate for an OpenG sub palette off the current Refnum palette. There should be a way to do this with scripting. Perhaps PJM's Private Class generator already has these. I'll check.

The problem with these kind of refnums (queue, notifier, event, etc.) is that they also hold type information, so the refnum type changes as the element datatype changes. So there's not really one refnum-type for a notifier or a queue.

What would be nice to have is if NI gave us 'empty' refnum controls for queues, notifiers, etc. in which we then could drop whatever control we want to be the datatype (analogous to what now is possible with the datalog refnum) for that specific object. This would certainly make life easier since now I have to keep two seperate typedefs (one for the data type and one for the refnum type) for every queue or user event I use in my apps. I'd like to see these two connected somehow.

[delbertson]

The problem with these kind of refnums (queue, notifier, event, etc.) is that they also hold type information, so the refnum type changes as the element datatype changes.

Yeah... I guess that makes sense.

Thanks everyone for the help it's appreciated

[Mike Ashe]

The problem with these kind of refnums (queue, notifier, event, etc.) is that they also hold type information, so the refnum type changes as the element datatype changes. So there's not really one refnum-type for a notifier or a queue.

Agreed. You either end up with a palette full of the standard types (U8 ...DBL, STR, etc) plus you still have to make custom clusters, or...

What would be nice to have is if NI gave us 'empty' refnum controls for queues, notifiers, etc. in which we then could drop whatever control we want to be the datatype (analogous to what now is possible with the datalog refnum) for that specific object. ...

.... or you try to approximate this by using a queue of variants, which I have done several times, but we all know the pros & cons of variants. It seems with the added polymorphism we are seeing lately, that the "empty queue" refnum you are asking for should be a reality soon. I wonder if this can be done with an X control?

[Aristos Queue]

What would be nice to have is if NI gave us 'empty' refnum controls for queues, notifiers, etc. in which we then could drop whatever control we want to be the datatype (analogous to what now is possible with the datalog refnum) for that specific object.

You can already drop whatever type you want onto the queue/notifier refnums. Drag any control over the type display (the FPTerminal drawings) of the queue/notifier refnum, and it'll accept the control and update the type display. You can also popup on them and choose "Show Control" to get a more "datalog refnum" sort of view.

This would certainly make life easier since now I have to keep two seperate typedefs (one for the data type and one for the refnum type) for every queue or user event I use in my apps. I'd like to see these two connected somehow.

If you create a queue of a typedef, the queue knows that it is connected to that tyepdef, and so when you update the original typedef, the queue is updated. There's no need for a second typedef of the queue itself.

[Jeffrey Habets]

You can already drop whatever type you want onto the queue/notifier refnums. Drag any control over the type display (the FPTerminal drawings) of the queue/notifier refnum, and it'll accept the control and update the type display. You can also popup on them and choose "Show Control" to get a more "datalog refnum" sort of view.

If you create a queue of a typedef, the queue knows that it is connected to that tyepdef, and so when you update the original typedef, the queue is updated. There's no need for a second typedef of the queue itself.

Stephen, you're the king.. :worship:

I don't know why I never noticed this feature before.. I just checked and it is possible since at least version 7.1.

So we now only need to put some refs in the control palettes to make them easier accessible..

Thanks!

[Aristos Queue]

I just checked and it is possible since at least version 7.1.

Since LV6.1, when the queues/notifiers were refactored to not use CIN nodes but become language primitives.

[baptie]

Working on a joint application with delbertson, got notifiers working for alot of different user inputed reentrants, is there any 'simple' way to get outputted indicators from each individual reentrant VI. :headbang:

We have AC Motors, Stepper Motors & Sensors all split over multiple reentrant VI's, it would be great to get some feedback onto the Front Panel Main application.

I can get the indicators updating in the actual reentrant VI but not in the Main application, as far as I can see from 'Help' and web site sources this is not possible without initialising VIServer, is this correct :question:

[ned]

Working on a joint application with delbertson, got notifiers working for alot of different user inputed reentrants, is there any 'simple' way to get outputted indicators from each individual reentrant VI. :headbang:

We have AC Motors, Stepper Motors & Sensors all split over multiple reentrant VI's, it would be great to get some feedback onto the Front Panel Main application.

I can get the indicators updating in the actual reentrant VI but not in the Main application, as far as I can see from 'Help' and web site sources this is not possible without initialising VIServer, is this correct :question:

Perhaps I'm misunderstanding your problem, but you can use notifiers for your outputs, too.

[Aristos Queue]

Working on a joint application with delbertson, got notifiers working for alot of different user inputed reentrants, is there any 'simple' way to get outputted indicators from each individual reentrant VI. :headbang:

We have AC Motors, Stepper Motors & Sensors all split over multiple reentrant VI's, it would be great to get some feedback onto the Front Panel Main application.

I can get the indicators updating in the actual reentrant VI but not in the Main application, as far as I can see from 'Help' and web site sources this is not possible without initialising VIServer, is this correct :question:

I really don't know what you're asking for here. I think a demo VI would help a lot. Can you post a simple example of the problem?

[baptie]

This is a demo Front panel of a Plate Motor VI : http://img179.imageshack.us/img179/1776/fplv0.jpg

A Simple Start/Stop, Faster/Slower & Forward/Reverse. We have abbility to get speed fed back from motcan.vi

This is the Plate Motor VI Block Diagram : http://img160.imageshack.us/img160/562/vidiagun4.jpg

This is MotCan.VI, I can get the fed back motor speed (Actual Speed) within this VI but not on Plate Motor.VI Front Panel : http://img405.imageshack.us/img405/2547/motcangv3.jpg

Actual Speed is connected to a terminal of MotCan.VI's Icon

Hope this kinda clears things up

[Neville D]

This is a demo Front panel of a Plate Motor VI :

A Simple Start/Stop, Faster/Slower & Forward/Reverse. We have abbility to get speed fed back from motcan.vi

This is the Plate Motor VI Block Diagram :

This is MotCan.VI, I can get the fed back motor speed (Actual Speed) within this VI but not on Plate Motor.VI

Hope this kinda clears things up

Why don't you just use the lower-level VI as the top-level VI?

From the block diagram of the PlateMotor.vi, it doesn't look like its doing anything special; add the stop functions to the end of the lower level VI.

Another approach is to use sub-panels to display the lower level VI in the Main VI's window. That way you have complete control of the subVI's front panel controls AND you can view its indicators.

here is a picture from my code, of how you can load a subpanel of MY SUBVI.vi:

-------------Later Edit--------------------

Sorry, just re-read your post.. subPanels will NOT work with re-entrant VI's.

You could try:

1 writing your indicator values to a regular global, and reading the global in the top-level VI.

2 same approach but with a buffered shared variable so as not to lose data.

3 slightly more complicated but in the same vein: use a Q to write data in the lower-leve VI, and read the Q from the top-level VI.

Neville.

[ned]

At the risk of repeating myself... just create another notifier, like you did for the inputs, but this time put the "Send Notification" inside of MotCan.vi, and the "Get Notifier Status" inside the while loop of the Plate Motor VI. Wire the actual speed as the notification to be sent and you'll be all set.

[Neville D]

At the risk of repeating myself... just create another notifier, like you did for the inputs, but this time put the "Send Notification" inside of MotCan.vi, and the "Get Notifier Status" inside the while loop of the Plate Motor VI. Wire the actual speed as the notification to be sent and you'll be all set.

I think the main issue here is the "multiple re-entrant" VI's. Using notifiers of the same type from multiple VI's causes problems. See notifier signals missed for a recent LOONG discussion on an "issue" (note I didn't say bug!) with multiple notifiers of the same type. As explained by Aristos Q: due to some performance related reasons, you are likely to miss some notifiers.

You are better off using even a single elem Q as opposed to a notifier in such a case (a notifier is a lossy single element Q anyway...)

Neville.

[Aristos Queue]

I think I understand. Tell me if this is right:

You have, currently, data in PlateMotor.vi that you send to MotCan.vi using a notifier. What you want is to be able to also send data from MotCan.vi to PlateMotor.vi. The data updates on the FP of MotCan.vi (when you write to the indicator's terminal) but you don't know how to get it up to the calling VI without using VI server.

Assuming all of the above is correct, then the answer is straightforward. Have PlateMotor.vi create a second notifier and pass that notifier as a parameter to MotCan.vi. When MotCan writes to the indicator terminal, it should also use Send Notification to update the notifier. In PlateMotor.vi, you already have one loop that is updating the first notifer. Add a second while loop to PlateMotor.vi which does nothing except Wait for Notification from that second notifier and updates its own FP indicator every time a new notification becomes available. When the MotCan.vi is finished running and ready to return a value, use Release Notifier. This will invalidate the notifier refnum, causing the Wait For Notification node to return an error, thus giving you the stop condition for the while loop in PlateMotor.vi.

Does that help?

[And, as other posters have mentioned, if you need to catch every value, then use a queue instead of a notifier in the instructions above.]

[PeterB]

Hi I'm just new to Labview and have a bit of a newbie question. I have set up and Tested a VI to control a motor via the CAN_Open protocol, and it's working fine. It's currently in a timed while loop. It has a Dial control for speed a latch button for on/off and a radio button to select it's direction of rotation. I'm my final application I'll require 3 of these motors with exactly the same controls though the Max and min speeds will be different, as will it's coms ID. I'd like to be able to just include this VI, pass it the Max and Min values etc and replicate it on my front panel and use it like a user control. If I hide all the controls used as I/O to the VI leaving only the user controls, and make the VI reentrant.... I can get more than one instance of my VI to run in separate windows... but I'd prefer to have them on a single user interface. Is this possible and if so could any of you Labview experts point me in the right direction or to a url with an example of this type of thing? Thanks in Advance. Derek

Hi Derek,

I'm coming in late on this thread as I've only just caught up on reading a lot of posts.

I have a question for you. In order for the motors' speed (or other parameters such as max, min) to be set, do the commands need to be sent regularly to the motor in a timed loop even if the operator has not adjusted the speed, min or max control setting?

regards

Peter

[baptie]

do the commands need to be sent regularly to the motor in a timed loop even if the operator has not adjusted the speed, min or max control setting?

The plate motor.VI is a snippet of a much larger User Interface. We are going to have 3 seperate motors, 6 stepper motors, Temp Controller And two Air Controllers.

The ID, Min & Max are there to enable Whoever is designing the user interface to add Min/Max Speed Values for the connected motor and input an ID that is Drive specific,

If we didn't add these items here, the re-entrant method would not work right for the method that we are using.

Big thanks to all, Aristos Queue Implemented your last post word for word.......worked a treat. We now have feedback to the Front Panel of the user Interface. TY

[PeterB]

[/url]do the commands need to be sent regularly to the motor in a timed loop even if the operator has not adjusted the speed, min or max control setting?

The plate motor.VI is a snippet of a much larger User Interface. We are going to have 3 seperate motors, 6 stepper motors, Temp Controller And two Air Controllers.

The ID, Min & Max are there to enable Whoever is designing the user interface to add Min/Max Speed Values for the connected motor and input an ID that is Drive specific,

If we didn't add these items here, the re-entrant method would not work right for the method that we are using. <snip>

Hi baptie,

unfortunately you didn't answer my question, however after I took a closer look at ther code you posted, I was able to understand what you are doing.

You are using a notifier as a local variable, and you are POLLING its values (speed, direction and 'enable') once every second. The solution you have implemented does work but it has the following drawbacks:

• the lag time of up to 1 second could be annoying for the operator.
  
• With the number of motors you have to simultaneously control, a scalable polling architecture could begin to place an unecessary burden on CPU usage.
  

I would like to suggest that if you have the time (or in the future) that you consider using the full capability of notifiers (or even an event structure) to implement an EVENT based architecture rather than a POLLING based one. Such a solution would be scalable without wasting additional CPU time when idling. By 'idling' I refer to the time when the user is not changing any controls on the front panel.

If you are interested in knowing more, I am happy to write some details on the topic.

regards

Peter