more elegant solution for translation

[frakintosh]

I'm working on a solution for moving a third party (Newmark) translation stage in the x and z axes at 10cm increments while stopping at each movement, querying the position, sending a command to gate a triggered pulse from a microwave pulse generator and collecting the magnitude data (voltage) from the triggered pulse event to the end of the returned scattered wave via a real time scope. Similar to a radar event. I need to (1) move to position, (2) record position (txt or spreadsheet), (3) gate the triggered pulse, (4) start recording voltage values from gated pulse to end of reflected wave, (5) record values over this time window to they correspond to the position in the same txt or spreadsheet. 

Now, I know there is a lot here so if anyone would like to offer any advise I would appreciate it. I have some basic commands to gate the trigered pulse from the pulse generator (Picosecond), and I have some vi's for the real-time Tektronix scope (DPO7000 series) for collecting data over the time window. My first concern though is developing a more elegant solution for the translation over x and z. Basic commands for movement are, for example, az;mr10;go;ru (axis x, move relative 10 mm, go, report position). My clunky way of doing this was a for loop for a number of iterations in the x-dir and recording position in an array at each iteration. Then I supposed I would set a sequence where at the end of the iterations i would home the x stage, increase z-dir by 10cm and loop again. I'm not a programmer but I run a home-made cnc and this seems clunky. I would appreciate any advise on this, or any examples if you've done anything like this. Thanks.

[JÞB]

It may seem clunky to you but it is robust.  those newarks can skip a spet here or there  and the  command set isn't exactly modren.  Robustness trumps elegance in this case IMHO.  Good question. stick with what works unless a real requirement is not being met.

[frakintosh]

oh, I'm not saying the hardware or command set isn't robust, I'm just wondering if there is a better way of executing the moves. I think the control system is fine, I just don't have much confidence in how I am implementing it...thanks for the response...

[JÞB]

Well, then attach the code we'll peek  (a link to the manual would help refresh my memory too)

[FraggerFox]

---

@frakintosh wrote:

 I think the control system is fine, I just don't have much confidence in how I am implementing it...thanks for the response...

---

From what you explained, it seems a preety good way to go out and take the position each iteration.

Still, if you could post your VI, members here could peek in and have some optimization advice for you.

[frakintosh]

Ok, here is the vi. Bretty basic. I thought I would add two more cases in sequence to allow for -z-dir movement then another for a +x-dir movement. THis would allow for two rows to be traversed, then I could loop the 4 case structure to cover my area. What do you think?

[JÞB]

From what you discribed in your original post I understand you may need to operate on the values you recieve from the stage ( position ) as they are recieved and trigger aditional equipment as the information becomes available.

You are right- you need a different (though not necessarilly more elegant) solution.  The base design pattern of your example will not adapt to your needs.

So lets dive in and look at a design patterns that will get you there- No need to re-invent the wheel.  You may need to take a good hard look at some of LabVIEWs shipping examples though and engage some grey matter.

First look at "Standard State Machine" (File>>New...>>VI\From Template\Design Patterns\Standard State Machine)  and do a forum search for State Machine as well.  You have allready defined your states (Mostly) <"Initialize", "Move", "Get Pos", "Read V Waveform", "File", "Calc Next Movement", "Clean-up", "Exit">

Now you have an experiment,  If you also need to keep the user/operator in the discision process (like to abort a run or change parameters durring a run) we can add a touch of elegance by expanding the state machine to a Queued State machine implementing a Producer-Consumer design pattern. (Check the same sources).

Keep us informed of your progress. Don't hesitate to ask about concepts that are new to you.

(Heck, you got two LabVIEW Champions to respond so far...  This could be an interesting thread)

[frakintosh]

Ok, thanks for the help. I'm working on that basic structure now. Feels cleaner this way...