I added a square hole with a radius in each corner and was able to select all faces individually from the back of the part without any problems, so this problem appears to be restricted to round holes. I later noticed that I could select the holes from the front, but even then I had to click on just the right place on the curved surface. Regardless of where I click around the hole the bottom surface of the part is always selected, as though the bottom surface was also covering the holes. I had to flip the part to machine the holes from the back which is no problem for Sprut 7. The part was drawn in Alibre and exported directly into Sprut. Unfortunately I couldn't select insides of the holes! I could select all other faces, but not the curved surfaces of the holes. For a short program or something that will be run many many times it might be acceptable to run it slowly while monitoring the process, but on one-off jobs that might take multiple hours to process it’s simply not an option to run blindly the generated code without going through a sim stage.I cant wait for 9, 8 was good but lots of little bugs.I downloaded the trial V9 Build 1.9 a couple of days ago and I decided to start with a simple part that I need to make, basically three interpolated round holes in a profile. It will run, but at no point is the robot motion simulated beforehand to make sure it is safe to run, as Robotmaster or SprutCAM Robot do. We evaluated the Fusion360 for example and it is only a naive post-processor with proper URScript syntax output. To my knowledge there is no desktop client app to control a UR bot and execute/follow a gcode trajectory over the realtime ethernet connection, we prototyped something once where we executed the gcode on the laptop and streamed the TCP to the robot so that it was essentially mirroring the virtual machining op, but I dont know of existing out-of-the-box solution, something similar to If i’m not wrong, all these solutions do not simulate the robot kinematics before generating machine code, so there is always a risk when executing these blindly to crash or enter into a singularity/exceeding kinematics limits. You could also stream the toolpath from a computer over ethernet, that would allow for infinitely long programs. ![]() You might be able to write a script that could load dynamically a csv file or similar with a list of waypoints and loop through them to create a path on the fly but then you would still need to validate the toolpath beforehand as you could quickly crash/reach some limits, or be constrained to a working range you are sure is reachable. I dont know how the e-series behave with very long programs, I guess 4.5MB brings you close to a hundred thousand lines? Also you wont be able to run straight g-code since you must convert that to urscript code first, and likely want to go through a simulation stage to make you sure you dont hit any singularity or exceed any kinematic limits, you cant simply replace the gcode commands with urscript syntax expecting it will just work. On CB controllers our experience is that a program more than a few thousand lines will take really long to start playing and very often crashes the controller.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |