Re : Serial Communication: Deciding amount of actions per coordinate

[Tresdin]

Hello everyone,

once again I need your help.

I'm controlling a device via serial communication. It's something like a robot arm which can move along a x-y-z-plane.

What I want to do is the following:

I want to pre enter single commands which the robot should do. After I entered all the comands I want to run the program.

For example:

1. I want to move the robot arm to the first position, when the arm is at this position it should do action a and b (a and b are random actions I know the serial commands for)

2. After he is done with action a and b at position one I want the arm to move to position two. At position two it should only do action b.

3. After finishing action b at point two it shall drive to point three and do nothing there etc.

4. Press "run" and let the robot do step 1-3

So I basically want to enter three commands at point one, two commands at point two and one command at point three and "save" them tempoerarly so I can start the program as soon as I tell it to run. This is just an example for three points (I want a variable number of points in the end, because sometimes I need 10, sometimes I need 23 points etc.). I want to individually program every point because I want to do different stuff at different coordinates.

I hope this is possible with LabView (I'm using 2012).

Thank you very much for your help in advance. I just need some guidance.

Best regards,

Tresdin

[GerdW]

Hi Tresdin,

yes, that's (nearly) possible with LabVIEW (and every other programming language)!

"Nearly" because serial communication is "serial" and not "parallel": you cannot send 3 command in parallel at point 1, you still need to send them in serial (but with very short delays in between)!

All you need is a "list" or an array of commands, with information added when to send these commands. Then you send those information at need to your device.

As you additionally want to monitor the device reactions I recommend to use a state machine approach…

[Tresdin]

Hi GerdW,

ok thanks. I phrased it poorly, I know that it's serial and that is not a problem. The serial communication is not a problem in this case for me.

[crossrulz]

I think an Array of Clusters would be useful in this situation.  The cluster should have your X, Y, Z, and then any additional commands (probably an array of strings would be easiest).  Then it is a simple FOR loop autoindexing on the array of clusters.  Unbundle By Name to get your X, Y, and Z to move the robot to where you want it.  If you go with the array of strings for the additional commands, then another FOR loop to iterate over the different commands.

[Tresdin]

Hi crossrulz,

thanks for your reply. I don't know if you remember me but from what I've done thus far I've used this approach. You gave me this idea a few weeks ago which worked very well.

I forgot to mention one thing maybe:

When I use an array of clusters it might get a bit confusing to change single coordinates or actions in retrospect. Is there a simple solution to this? Maybe something like a chart where the commands are automatically saved to? (Which I can alter afterwards if I just want to change one entry for example)

Furthermore: What if I want to enter the coordiantes x and y via a clickable pane? I know how to get the mouse coordinates. But can I connect a clickable plane with the array of clusters for different entries? This seems a bit complicated to me.

Thanks for your help

[Ericgo67]

Hi,

Well there are a few things that have to be taken into account for right operation of the robotic arm.

First of all, does your robotic arm provide feedback of its current position, throught a serial command? If yes, then u can poll the arm for its position, and decide when the robotic arm is in the right position, to send your command A and B, which is doable through a state machine in Labviez, sending a command in each state ( can be done otherwise but im trying to keep it simple)

If you have no feed back , then you 'll have to operate it blindly , through delays, sending yur positionning command waiting enough time to let your robot arm move to its position , and then send the commands a then b , as you wish. Once those command finished, you can then move on to the next position , wait x time for the movement to finishe and do your operations , and so on. Not sure what you mean with "preenter commands".

I guess your robotic arm has a buit in microcontroller that does the full control of the arm , and the serial communication just tells the microcontroller whet to do, but as we dont know the architecture of your project, answer might not be accurate enough.

Hope that helps

Eric

[Tresdin]

Hi Ericgo67,

thanks for your reply. Yes, my robot can send the position information as far as I know. In the programs I wrote thus far I used delays, I didn't know of the possibility you mentioned.

[Ericgo67]

Hi ,

I guess the feedback is naturally the best way to know when you can start to go to the next operation (means when you reach your final position )

As for the commands , a simple way would be to implement a vi for each serial command , and integrate it into you main program as wished. Minimal input would be the serial COM name or whatever you use azs serial link, and the Error input, optionnaly , u could set input as the paraemeters u use in your serial commands ( x, y , z for example) , making your command (VI ) resusable.

A command inside your VI would then be represented as an array of byte or whatever data u wish to send.

I guess Labview Purist might find better solution, using polymorphic VI or other stuff, but i aint deep enough into that kind of stuff to help you more on that way.

Eric

[Bob_Schor]

I know you've already put in work on this, but I want to suggest "something a little different".  How about designing a Robot Language for your Machine?  Think purely abstractly about what you want to do, and think what sort of Command and Parameters you might need.  For example:

   GotoXY X, Y    Moves X and Y axis (at default velocity and acceleration) to X and Y

   GotoXY X, Y, Xvel, Yvel     Use specified Velocities (assuming your Robot allows this)

   GotoXY X, Y, Xvel, Yvel, Xaccel, Yaccel

   GotoX X          Single Axis move (with optional Xvel, Xaccel, and similar GotoY Y)

   TargetXY X, Y  Same as GotoXY, except doesn't start the move, just "sets the intention to move"

   DoMove           Executes all pending Target commands

   Pause Secs     When following a Goto or Target command, waits before doing next Goto or Target command

   OtherActions   Whatever suits your fancy goes here, with parameters.

Now consider implementation.  You need a "Controller", software that lets you decide what you want to do and build "commands", which can be simple strings (as above), each string sent with an end-of-line character (so to a human, they "read like" a list of commands).  It is pretty easy to build, say, a GotoXY X, Y command -- it consists of the string "GotoXY ", and two numbers, written as strings, a very easy task for Format into String to handle.

You asked about putting X, Y coordinates in from a Graph and Cursor.  Easy -- handle Mouse events on your Graph, extract the Mouse coordinates, scale them appropriately, and you have X and Y.

In addition to the Controller routine (which generates commands as "Text Messages" send to the Robot), there's also the Robot software, which has two pieces -- a Listener/Command Formulator, and an Intepreter/Executioner.  The Listener parses the lines of text from the Controller, initially breaking it up into Command and Parameters (I used "single word" commands, so you can use a Space as the separator).  You now need to parse the Parameters, using rules specific to the Commands (for example, Pause has a single Parameter, interpreted as a delay time in seconds, while the Target Commands have a variable number of parameters, using default or already-known values for the "short forms".  Now you hand your Commands + Parameters to your Interpreter, which should probably look very much like a State Machine ...

Don't actually do this now, but think about the idea that you are, in some ways, designing some version of such a system, maybe not as explicitly encapulating it as I've done (and there are many ways to do this, probably much better than my simple-minded example).

Bob Schor