05-06-2022, 08:54 PM
Thanks Albert!
That is helpful to know. I am all sorted out in terms of accepting small lines over arcs. I can make it work, it's just a huge amount of data per finishing pass to feed my older robot (a whopping 60mb!).
I'm going to keep experimenting with methods of feeding these large files to my Staubli controller. Do you know if it makes sense for each of my "chunks" (22,000 line chunks of the larger milling pass) to include all the info in the header? I would think it's important to keep the program name, define the base, and the TOOL TRANS. It seems less important, or even problematic to include the joint position and "above" move, provided I go from the end of one chunk to the beginning of the next without changing positions.
As I'm still switching between floppies and start/stopping this program manually I occasionally create a postion with a higher Z number at the end of a chunk. I then use a MOVES (straight line move) to move the tool above the workspace without changing the tool position. This allows me to shut off the router and take a break, ect. I am trying to figure out how important it is to go back and assume the #PPPOINT (joint pose) prior to restarting the next chunk. It either requires a lot of manual editing on my part to make that happen, (to bring me back to the correct "above" location.) I am wondering if the robot will slowly "forget" that original joint pose - or if the moves commands keeps everything accurate?
If repeating the starting pose isn't so important I may try and add to the end of each chunk a MOVES command that does what I do - move the tool up 50mm or so. At beginning of each subsequent chunk I would require a confirmation from me to descend 50 mm down. This would be nice as these simple commands would be relative to the robot's location wherever it is throughout the milling pass and I wouldn't have to manually enter Z coordinates on each of 50 or so chunks.
Below is what Robodk produces (I removed the extra info)
.PROGRAM F1()
BASE 0,0,0,0
SPEED 70.0, 100 MMPS ALWAYS
TOOL TRANS(136.400,-12.630,64.600,-3.396,88.999,57.254)
MOVE #PPOINT(65.52000,-78.58000,200.50000,-21.46000,-32.71000,17.00000)
MOVES TRANS(69,611,0,0.000,180.000,-19.680)
SPEED 66.7, 100 MMPS ALWAYS
(after this point 22,000 lines of "moves" commands and coordinates.)
I imagine you guys support file splitting on many of the contemporary robots, and have clever ways to do it. If you have any advice I am all ears. On the other hand, I feel like ya'll have helped me out a lot already, and I can probably sort out methods to get this done. No worries if things are busy.
Thanks so much for helping teach my classic robot some new tricks :) The scope of what RoboDk is doing is pretty incredible. Once I sort more of this out, and if you guys are interested, I'd be happy to document my wood milling experiments with photos, videos, and a write-up. Although I completely understand if you have enough of that stuff.
David
That is helpful to know. I am all sorted out in terms of accepting small lines over arcs. I can make it work, it's just a huge amount of data per finishing pass to feed my older robot (a whopping 60mb!).
I'm going to keep experimenting with methods of feeding these large files to my Staubli controller. Do you know if it makes sense for each of my "chunks" (22,000 line chunks of the larger milling pass) to include all the info in the header? I would think it's important to keep the program name, define the base, and the TOOL TRANS. It seems less important, or even problematic to include the joint position and "above" move, provided I go from the end of one chunk to the beginning of the next without changing positions.
As I'm still switching between floppies and start/stopping this program manually I occasionally create a postion with a higher Z number at the end of a chunk. I then use a MOVES (straight line move) to move the tool above the workspace without changing the tool position. This allows me to shut off the router and take a break, ect. I am trying to figure out how important it is to go back and assume the #PPPOINT (joint pose) prior to restarting the next chunk. It either requires a lot of manual editing on my part to make that happen, (to bring me back to the correct "above" location.) I am wondering if the robot will slowly "forget" that original joint pose - or if the moves commands keeps everything accurate?
If repeating the starting pose isn't so important I may try and add to the end of each chunk a MOVES command that does what I do - move the tool up 50mm or so. At beginning of each subsequent chunk I would require a confirmation from me to descend 50 mm down. This would be nice as these simple commands would be relative to the robot's location wherever it is throughout the milling pass and I wouldn't have to manually enter Z coordinates on each of 50 or so chunks.
Below is what Robodk produces (I removed the extra info)
.PROGRAM F1()
BASE 0,0,0,0
SPEED 70.0, 100 MMPS ALWAYS
TOOL TRANS(136.400,-12.630,64.600,-3.396,88.999,57.254)
MOVE #PPOINT(65.52000,-78.58000,200.50000,-21.46000,-32.71000,17.00000)
MOVES TRANS(69,611,0,0.000,180.000,-19.680)
SPEED 66.7, 100 MMPS ALWAYS
(after this point 22,000 lines of "moves" commands and coordinates.)
I imagine you guys support file splitting on many of the contemporary robots, and have clever ways to do it. If you have any advice I am all ears. On the other hand, I feel like ya'll have helped me out a lot already, and I can probably sort out methods to get this done. No worries if things are busy.
Thanks so much for helping teach my classic robot some new tricks :) The scope of what RoboDk is doing is pretty incredible. Once I sort more of this out, and if you guys are interested, I'd be happy to document my wood milling experiments with photos, videos, and a write-up. Although I completely understand if you have enough of that stuff.
David