HALRobotics / Beta

HAL Robotics Framework beta release and associated documentation.
17 stars 3 forks source link

Code export error for KUKA setup #80

Closed anjakunic closed 3 years ago

anjakunic commented 3 years ago

Dear HAL team,

I have been trying to develop a workflow using KUKA robot (KUKA KR240 R3330) mounted on a linear track (KUKA KL4000 ) and a positioner (KUKA KPF1 V500 V1). As KUKA external axes are not pre-defined, I have developed custom mechanisms. The simulation seems to work all right, but when I try to export the code, an error appears (see attached image).

I have also tried to export the code of your example file "Resolve targets", which as well has a custom mechanism, and it seems to have the same error.

Could you help me with this?

P.S. Sometimes the code got exported (when using only the positioner + robot and no rail) even though the "Export" component showed the error. However, in the code there was no positioner-related coordinates (e.g. E1 0), so the robot could still not be moved.

Screenshot 2021-01-25 180507

sebandraos commented 3 years ago

Hi @anjakunic , Have you had a look at the export help here? That should do something to help, particularly the nesting of child procedures. With that minor change, the demo files I received the other day produce good looking code: image

Regarding those demo files: Assuming you are actually doing a small enough toolpath that the track doesn't actually have to move, I would recommend using a single synchronous move for all the mechanisms and then running the toolpath for the robot and ten another synchronous move for all mechanisms to get them ready for the next phase. With this strategy, you could also synchronise the track and robot if you wanted/needed to. This is shown in the file I sent to you by email (not sure how confidential the models are - please let me know if I can upload it here to help others). Please note that within that file, the Kinematic Settings have been rerouted so as to only be used in synchronous actions, and SyncSettings can only be used once so the main robot motion would need to be duplicated if it is synchronised with the track.

sebandraos commented 3 years ago

I believe the changes mentioned fix the issue but please reopen if there is still a problem.

anjakunic commented 3 years ago

Hi Sebastian,

Thank you very much for these indications and corrections in my file. The model is not anything confidential, so feel free to share it with everyone.

I still have one doubt regarding the possibilities of synchronization of multiple actions. I am not sure I understood it correctly but is it true that it is not possible to have the rail movement happening in automatic, in relation to the target location, while having it synchronized with another action (positioner movements)?

I saw that you specified the robot positions along the rail for the specific targets through the slider, but this might require a large number of sliders later on if doing some more complex multi-operations.

I am not quite sure I understood the part where you said I should duplicate the main robot move if sync with track needed. Does this solve the question above?

If I duplicate it do I still merge the two robot programs (e.g. milling a block with sync settings 1 and picking it up with sync settings 2) into a single "combine actions" component to then feed it to the controller as one action regarding the robot mechanism; or do I add these as the (fourth in my controller) individual action and related mechanism (in this case I have the robot mechanism twice input in the controller and this results in some errors)?

Thank you in advance and I apologize for the long list of questions.

Best, Anja

sebandraos commented 3 years ago

is it true that it is not possible to have the rail movement happening in automatic, in relation to the target location, while having it synchronized with another action (positioner movements)? The way it needs to be considered is more as a individual mechanisms - if you want the track to move at the same time as the robot and the positioner, then that's entirely doable but you're synchronising all 3 mechanisms not track+robot sync'ed with the positioner. The other thing to note in that scenario is that you'll need to change SyncSettings when changing kinematic grouping i.e. SyncSettings1 for Robot, Track and Positioner, and SyncSettings2 when you switch to Robot and Track only.

I saw that you specified the robot positions along the rail for the specific targets through the slider, but this might require a large number of sliders later on if doing some more complex multi-operations. Yes, that was just to force a visible motion of the track during the sync change. You can absolutely use the TargetResolvers for that.

I am not quite sure I understood the part where you said I should duplicate the main robot move if sync with track needed. In the attached file (same as I sent you), I reused the Robot's milling Procedure twice in main Robot Procedure. This is fine when it is run asynchronously but SyncSettings cannot be reused so if that Procedure were to be Synchronous there would need to be 2 distinct Robot Milling Procedures, rather than 1 Procedure used twice. The second Robot Milling Procedure would indeed go into the main merge for the Robot Procedure. It's always 1 Procedure per Mechanism in the Controller. That sounds a little complicated but hopefully makes sense in the context of the file.

CREATE KUKA setup - robot+rail+positioner_Async.zip

anjakunic commented 3 years ago

Thank you Sebastian a lot for your answers and explanations.