Comments on Code

[nathand]

Don't take this the wrong way, but... every time you explain one more bit of your code I look at it one level deeper and realize how complicated you've made something that should be simple.  Let me see if I've got this straight.  The bottom loop continuously reads the contents of a cluster through a reference, and continuously generates Value Change events that are handled by the third loop down.  On each of those events, that third loop checks to see if any value actually changed, and if it did, then it puts an item into a queue for the second loop down to handle.  The bottom loop also occasionally generates actual user events that are handled by the top loop, which in turn also puts elements into the queue for the second loop to handle.  Have I covered everything?  Does this seem like an efficient, functional architecture?

References are generally a slow and inefficient way to transfer data.  Consider handling the user interface events one level up, on the block diagram where the control is located, and then using a queue to pass data to the subVI.  That way you can register for events on the items you actually care about, and you'll keep the logic separate from the user interface.  It's is possible to wire a control reference to Register for Events to get events on the referenced control (which can be in another VI), but you lose the ability to register easily for events on individual controls within a cluster unless you want to register for each of them independently.  I'd let this wait until you've done more LabVIEW programming.  I don't think there's any need for an event structure inside the subVI, and definitely no need for more than one.

[crossrulz]

pierroil, can you zip up your entire project so we can see what you have done so far?  It is really hard to comment on architecture without playing with actual code.

[pierroil]

Yes, you have it right lol.

So given this consluion that I should go monitor everything at a higher up level - that higher up level will one day itself become a subVI. I essentially want my motors to alwasy be running in the background and I want to send them commands.

How do I do this?

I know it`s not efficient but it is working and I can't find a better work around with the knowledge I have - I need this piece of code working.

"and then using a queue to pass data to the subVI"

So i would queue the fact that an event was registered. and use a SubVI for all the logic. That sounds promising, and could work actually

Now I want to replicate thsi 4 times. I want to monitor 4 clusters, I guess the event loop would monitor all of the clusters events? One giant state machine? I guess that works and it woudl reduce the amount of loops running in parrelel. 

Is that right? I can probably make this change in a few hours tonight.

[pierroil]

By the way: I moved the Queue loop to my higher up level. Those VI`s have now become purely producer loops - producing Queue commands and my consumer loop is on on the higher level VI. It seems to work well. It will also ensure that my communication line ( single RS232) is only fed one command at a time - one read and write operation essentially.

[pierroil]

Ok I will zip everything in 1 hour - I`m just adding in an encoder to the mix to get the user events working and online. Already coded, now trying to get it all to fit in my confusing architecture 😛

[nathand]

---

pierroil wrote:

So given this consluion that I should go monitor everything at a higher up level - that higher up level will one day itself become a subVI. I essentially want my motors to alwasy be running in the background and I want to send them commands.

How do I do this?

---

I think you should monitor the user interface elements at the top level - NOT in a subVI.  That way you can easily register for value change events on only the cluster elements that you care about.  If you're going to have multiple identical clusters on the front panel, you can register for an event in the same element in each cluster within the same event case.  With a little bit of comparison of control references, you can determine which cluster generated the event and put an element in the appropriate queue.  Will try to throw together a quick VI demonstrating this idea if it's not clear.

There's no problem with having the motors running the background.  What I'm recommending is that you not mix that function with the user interface elements.  Keep them separate, and use a queue (or notifier, maybe a functional global if appropriate) for sending commands from the user interface to the motor loop.

[pierroil]

You do not need to make it more clear - I understand - it will just change a lot in my code and I can`t spend my time doing that right now. I`ll take a look tonight on my own home machine and not at work.

Open the Zip --­­> Go To --> Main Motors.vi

These files are a chunk of my code. You won`t be able to run it since you don`t have the motor controller. The SUB Vi`s inside the architecture madness all work. I`ve tested them individually and they are all simply logic. Some are deep, others aren`t. 

Most of the VI`s are simply in charge of setting up the write and read and interpreting the outputs from my motor.

Most of what you will need will be located right the Go to Folder

Here is my code: You can`t run it - for one you won`t have my machine so you won`t know what`s going on. Also, I`ve removed all my debug tools sine I don`t need them anymore.

By the way, you should know that I`m not trying to get a USER to control this entire device. I`m trying to get a SUPER VI to control these motors. That VI will send commands and this is why I liked references, it allowed me to build upwards with ittle consideration of the UI.  If you take look you`ll notice that I have a bollean controlling Reference to Cluters vs actual clusters. This will allow me to link everythnig upwards while making this sub vi do it`s thing - control the motors. 

Your new model would fit in this particular sub part of the project, but later, I won't be able to register events when I switch to "Reference mode".

[pierroil]

Also: Yes i am aware there is a programtical way of getting the right file path - I just didn`t bother doing it yet.

[pierroil]

I guess what I`m trying to say is: Can you find me an architechture - and i will actually change my entireee code if it`s possible, that will allow me to send values from a higher up VI? 

My final acrchitecture will be 3 control systems running in parellel. One of them will be fetching some Waveform and use a peak detect function to find the peak. identifying the peak, I will need to save the location of my waveform. That is only 1 point of data. I need to map an entire 2D map (Y and Z) and find the peak at every location on this map. This map has about 2000 points - I will be grabbing data at a specefic encoder count. Then I will find the optimal point and bring my motors back to that position. I will save that waveform and I`ll be done.

So far I have the DAQ set up for the waveform and the peaks (still working with some of the Peak functions). I also have the function that allows me to control my motors - this huge architectural nightmare right now. I`m going to integrate it with my encoder function today and then I just need to build the search and data fetching functions.

As you can notice: I`ll probably never need the UI. I don`t really care for it. So long as I can safely send a : Go to Position 50, or Go to Position 5 and I can make it, I don`t really care. I also want to be able to sweep a map so I incorporated a speed function. The search algorithm will be tricky, but I`ve been focusing on making sure my motors work properly so I can simply code some logic and I can finish the project.

I have a final control system that is a very basic UI. The user selects the test and the machine does it. By "Test" I mean the big chunk of logic I have yet to code that is going to be well above this motor VI. 

[pierroil]

My other option is 4 globals. That will have your architecture and I will be able to alter them from a top level. I just wanted to avoid them when I started this.