I have a problem with setting up my virtual tool and initiating movement with my state machine.
VirtualTool:
I needed virtual tool set, so I can use it later on, but I am not sure how to input the variable for the ToolParameters corectly. (now it is just comented so I could test some other stuff)
State machine:
I created basic state machine to test commands to start movement of a robot. I am able to power it on, home it etc., but I am pmissing something when it comes to initiating the movement. As on the picture bellow, if I put in the command, everything will get set, like speed, acceleration etc., but the movement won’t start and I am not even getting any error, so I am not sure, where the problem is.
Yes, thank you very much for your help, that was indeed the issue.
I am not sure if I can mark mutliple answers as a solution in a thread, so for now I am not going to do it, since the virtual tool isn’t corrected yet.
In Generall i would like to recommend you to have the Programming like this…
Parameters
Command-Flag
Functionblock-call
With the Start of an Command the required Parameters are Updated once, so you don’t need the Update if the right parameters are set upfront to the Command and Functionblock call.
ToolPar.X
ToolPar.Y
SetToolPar();
You did not descriped much about your isse with setting the Tool, but i think it could be related to the fact that the standard modal behaviour of the AxesGroup ToolFeature is “Use Axes Group Setting” and this is “Reset to Default”. If handlings Parameters outside of an Movement Programm i made the expirience that it is better to set up the modal behaviour to “Keep Values” so there is no internal Reset of the Values at Program Start.
The Tool contans the X,Y,Z Parameters which descripe the Tool, the Coordinate System is dependent to the Robot-Mechanical Model. Its the Coordinate System drawn next to the Robot in his Home Position.
For a Delta you need -Z to have a Tool looking down as Far as i remember
For a 6Axis Robot a Tool looking Forward would be +X
The Parameter Lenght of the Tool is considered to the Active Main Plane in XY its looking Down -Z. If you change the Main Plane its Rotating to the changed Plane.
The virtual Tooltip is only for Lathe operation .
Greetings
Michael
I apologise for the lack of description.
The robot is 2 rotary axes arm in XY plane (Z=0), as for the tool, it really ins’t a tool, it has basicly no dimensions. For my custom mechanical library, I wanted to make solution chooser, where I can switch between automatic choosing of solution or elbow Up/Down. In different post, you sugested to me to use VirtualToolTip so by switching tooltips which have different calculation methods inside them to switch the solutions.
This is the basic state machine to choose the solution inside my InverseFunction:
And in my testing program for operating the robot, which is also used to test the movement, I wanted to make the choice selector, depending on what the user chose in the WantedMode:
My problem is, that I do not know what to put into the VirtualToolTip to choose different Tool pos, so it would switch the calculation inside my Inverse function. And since it is not a tool, I think I do not need to set any other parameters for the VirtualTool, but I might be wrong about that.
Thanks for the clarification of the usecase i did not got the Reference just by the name. As i am on the mobile phone i think i did not even looked at it.
It is true if you have a coustom Transformation which is only evaluating the Parameter ToolTip you can just ignore all other data of the tool.
In your code we see only that you have the wrong order of code lined you first call the Functionblock an then you manipulate the tool-data. This is what i wanted to explain you in the last answer. You have to consider the sequence of codlines. First Parameters for the Functioncall then call it.
The second thing i am missing is the fact that the Execute is only set TRUE but never FALSE. PLCopen Functionblocks with Execute Inputs starts only when seeing am Positive Edge at this Execute Input. If there is only TRUE all time it may start once but never again. If you see a DONE=True you have to set Execute to FALSE.
And the you only have to check how the modal behaviour is best for you, i still think “Keep values” would suite your applikation best, but i could oversee something, so please make your own desicion.
I hope this helps further. Please let me know if the Execute was somehow your stopper…
I did try to correct my mistake and set the “Keep values”, but I am now having two errors.
First error: Not really sure what the problem is, as I am only initializinh Mplink once. Picture with Error and my Initialization is below, I did try to move it from my Initialization Case state to program init, but there is still problem somewhere.
Second error: Sometimes it says I cannot SetToolPar in current state. I tried to copy MPLink and SetToolPar_axesgroup from Main_init to my Initialization in my main case if that was the issue, but it wasnt. The selection is outside of the main case of my state machine, so it can be changed independantly of current state.
Also I know there are more errors with different functions, but those shouldn’t be critical right now for the basic testing and can be ignored (i.e. McActualVelocity etc.)
There are some documented limitations in the transfer options regarding mapp Technology Packages. Here is a link to this documentation. Download Options
I think your issue with the “already used” Mapp-Link occured possibly after a transfer, as you did not released the old usage via an Exit-Task , and on the new Init-Task he tried to realocate the same ressource.
You can work around this via using this EXIT Code for all Mapp-Motion Mapp Functionblocks. Or you can change the Transfer Options to skip the INIT/EXIT.
PROGRAM _EXIT
MpAxis_0(Enable:=0);
END_PROGRAM
If you get the error with the “allready used” Mapp-Link on a regular boot up, there is some reusage.
2. Topic Functionblock can not be used in State
Each PLCopen Functionblock has a defined Set of States he is allowed to be operated. If he is used in an other State this Error is set up with the information in which other state the PLCopen object was.
In your case the entry in the logger shows that a functionblock was used in the State “GroupStartup” which is basicaly a initialisation Phase of the Axesgroup.
So i think you were just to erly to call the functionblock. I would recommend to read the current PLCopen State from the AxesGroup and wait until the right State is reached.
IF MpFlex.Info. PLCopenState = mcGROUP_STANDBY OR MpFlex.Info. PLCopenState = mcGROUP_DISABLED THEN
MC_BR_SetToolPar_0.Exectute := TRUE;
END_IF
MC_BR_SetToolPar_0();
