[BigStickers]

Hello,

We are evaluating RoboDK and running a test while on trial. We are attempting to import code from Fusion360.

We are able to generate a machining program that runs in simulation, generates logical code for our RV-13, and LOOKS like it should work. When we actually attempt to run the instructions on robot, the program hangs on the speed command (Spd), we've removed that command for testing and get to our first actual move position (a joint move), then RoboDK encounters an error, "Communication Error."

Exporting the code that is supposed to run when we check "Run on Robot" it is outside the memory limit for our robot so we cannot just import it, however the first few commands, including Spd run without issue including the first joints that error out on RoboDK Run on Robot.

We have attached the RoboDK File and really need to prove this software works quickly. We were supposed to have made a decision / test cut Monday, to order the software and do production by tomorrow. Our compressed time schedule makes everything else difficult, so why not this too?


Master Setup R2.rdk(尺寸:4.56 MB /下载:32022世界杯国家队名单75)

[Jeremy]

Hi,

In this case, Run on Robot isn't really an option as you would lose any "fluid motion" capabilities. There's a required handshake between the robot and RoboDK after each move with live connection, the robot needs to stop at each point, which is not suitable for milling applications. So no need to waste time debugging that now.

We need to use the post-processor.

I see that your program is about 40K+ lines, which is too much for the robot memory.
I never encountered that issue on a Mitsubishi, but I did often for other brands, mainly Fanuc.

As a first quickly achievable step, I could find a quick way to split the program every 5000 lines so you could load them on the controller one by one.
Would that work for now?

Jeremy

[BigStickers]

Jeremy,

As a stop gap that would work I think to break it up. Long term we have several applications where "what we are trying to do" is the end goal. They are both 5 axis milling and Waterjet cut applications. Unfortunately we are Mitsubishi primary and a Fanuc.

I can also trim down the cutting process. thinking we could stream it, I was a bit lazy in the optimization area.

你的头脑是什么ughts for the quick solution? We can work the long term issues as we go.

Don

[BigStickers]

Jeremy

我们使用实时控制MTX RoboDKthe Mitsu? limited to a response time 7.1ms(CR-750 controller) for commands? Could we simplify the CAM project to get it working? Longer moves longer command waiting period, happy communications... Looking at long term usage.

The Drip Feed function is the key value we see in the software. we would love to take advantage of loading a CAM file vs Spline to path in RT Toolbox.

Thanks,
Don

[BigStickers]

Also we are noticing on the posted code it is calling a mvc when that is a circle and it should be a mvr for arc interpolation. However the point data is incorrect for an MVC or MVR.

P7=(+736.26,+52.98,+194.31,-180.00,+0.00,-180.00)(6,1048576)
Mvs P7
P8=(+736.26,+52.98,+194.31,-180.00,+0.00,-180.00)
P9=(+738.69,+52.50,+194.31,+180.00,+0.00,-180.00)(6,1048576)
P10=(+740.75,+51.12,+194.31,+180.00,+0.00,-180.00)(6,1048576)
Mvc P8, P9, P10 (This should be an arc mvr)

It fails with 2810 alarm. this works in robodk simulation but fails in RT toolbox or on robot

So now even parsing the file is not really working. I do have the 2mb memory option coming Monday from mitsu automation locally.

Is this forum the only tech support? or is the support expanded after point of purchase? IE do you want my CC# now to speed this up or should we be looking at other platforms? Or is a trial license intentionally limited or modified to prevent a trial from completing complex workloads?

---

New update!

Going through the output code, in addition to determining that the Post Processor is outputting circles (mvc) vs arcs (mvr) when called. We have further diagnosed the issue and have been able to figure out how to make our SMALL (56 lines with point set commands) exported code actually work!

Either RoboDK's raw output, or the Post Processor is not outputting pose data on the first point for arcs when setting them, Therefore without the pose data the tool tries to 360/180 to hit a point on a linear move, which the robot deems impossible, cries, beeps, and begs forgiveness.

We determined this by manually attempting to do an mvs (linear move) between the points that were generated by RoboDK (P8, P9, P10 in our previous post). When we did MOVs we saw J6 do a bit of a whirly bird to hit the orientation and were a bit perplexed.

After adding the pose data MANUALLY to the file it works!

So our next steps are either completely re-write your post processor (which it seems like we should bill you for or sell separately?) or see if perhaps you have an updated Mitsubishi Melfa Basic post processor that doesn't ship with our trial? We literally have over 30 man hours into this problem to TRY software that we think really should work. We've involved our Mitsu Rep and Our resellers and burned countless favors to get this running.

This POC is intended to be used as a demo to our customers of our capabilities, and something we can show at Trade Shows (which we have coming up soon). All prior experiences with RoboDK have been extremely positive and I'm sure that there is a simple solution to our problem.

For additional documentation purposes, I'm attaching tool path output with MVC (what your post processor calls) and MVR (the desired path).

- Don

[BigStickers]

Monday afternoon bump. Would love some support so we can finalize this. Thanks!

[BigStickers]

Might need to move this thread to bugs.

Finding even more issues with the Mitsu post that ships with this. Aside from everything else above, it is adding approximately 3 Curve commands per 1, all with weird data points. This is creating multiple passes at one cut and just failing for our application.

Another bug - Your mitsu Post (that we have) appears to be used for the live robot moves, so all the code issues we've found in the output also exists INSIDE the software moves too...

What is the support turn around time for paying customers? Hopefully better than us lowly trial users?

[Jeremy]

Hi Don,

I'm sorry I didn't found the time to check the forum Yesterday.

First, thanks a lot for all this valuable information.
Mitsubishi is a relatively new integration for us and we didn't receive much feedback from the users.

I'm adding @Albertand @Phillipto the conversation. We will try to apply your recommendation as soon as possible.

If you purchase a professional license you have access to prioritized support via email using "Help"->"Request support".
But if you do, it may still take a few exchanges between the both of us to make bring the post-processor to a level you are OK with.
Our best is what I can guarantee as it's what we do (our best) every single day.

To go back to the dripfeed discussion, if you guys know how Fanuc works I can explain how the dripfeed does.
We create split the program into multiple files with an ID (Prog1 -> ProgN) and we create one Main calling all the subs one by one.
Then, using a Python script, we send the Main and the first 2 programs via FTP transfer.
We then start the Main and once the first program is completed, the Python script overwrites the first program with the third one. Creating kind of a first in first out situation and never overshooting the robot memory.

Jeremy

Jeremy

[Albert]

You'll have less problems if you convert all arc/mvc moves (MoveC instructions in RoboDK) to small linear moves by changing these settings:

1. In RoboDK, selectTools-Options-Program
   
2. SetMinimum arc sizeto 1 mm
   
3. SetMaximum arc sizeto 0.5 mm
   
4. SetMinimum step sizeto 0.5 mm: this option will make sure you don't export points closer than 0.5 mm so rounding has some effect. You'll probably also generate more compact programs. You can increase this value even more to have smoother movements, however, you may loose accuracy.