topic Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles in Fusion Manufacture Forum

Doosan Mill/Turn Post version 42585 will crash with synced spindles

nicolas6DNFL — Wed, 15 Jan 2020 10:50:32 GMT

There is a bug in the post where it will perform a cutting operation with the spindle stopped, if you have the Sub engaged and synced with the same speed (whatever that speed is, even 0 is a valid speed), it will silently not start the spindle.

The offending code is here in function startSpindle(tappingMode, forceRPMMode, initialPosition) :

...

line: 3759

if (syncStartMethod == SYNC_ERROR) {

if (isSpindleSpeedDifferent()) {

error(localize("A spindle start block cannot be output while the spindles are synchronized."));

return;

} else {

->>> warning("Won't start spindle")

return;

}

Who is the author of the post, how can I contact them ?

Thanks

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

seth.madore — Wed, 15 Jan 2020 11:25:11 GMT

I will flag the post processing team and ask them to look into this, thanks for the report!

This is of special importance to me, as I just bought a Lynx 2100 LSY 🙂

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

bob.schultz — Wed, 15 Jan 2020 14:11:15 GMT

Thanks for reporting this issue. Can you supply a test case that demonstrates this issue? If not, then please explain the scenario. The post should know when the spindle is stopped and should report the error, as the function isSpindleSpeedDifferent() should return 'true' when the spindle is stopped.

Thank you.

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

engineeringNCMXB — Wed, 15 Jan 2020 18:48:13 GMT

I really struggled with the Doosan post on 2000SY machines. It was so bad, I simply gave up. I fixed what I had time for in the post and used g-code pass through for the rest.

Spindle transfers and synchronous dual spindle indexing either never worked at all or were too fiddly to bother with.

Since then, I have been focusing on hard post development because I simply cannot wait for or tolerate having a post made by a programmer. In fairness, I did the same thing when I was using CamWorks and MasterCAM. I never found a post developer that had the capability of understanding and delivering what I wanted and needed.

My computer science background is helpful in this area.

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

nicolas6DNFL — Wed, 15 Jan 2020 21:20:23 GMT

Looking at this with fresh eyes and the output G code should actually alarm out before getting to cutting as it's trying to open the main chuck while the main is spinning.

See attached test file and output code

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

bob.schultz — Wed, 15 Jan 2020 23:54:32 GMT

Looking at your code, this is what is happening.

Synchronize the spindles.
Unclamp the secondary chuck.
Grab the part with the secondary spindle.
Clamp the secondary chuck.
Unclamp the main chuck.
Pull out the part 28.25mm.
Clamp the main chuck.
Leave the spindles synchronized.
Cutoff the part.
Turn off the spindles.

Is this what you are trying to accomplish?

In this output I do not see where the spindle is turned off, except at the end of the program. Can you let me know what block is turning off the spindle prior to the cutoff operation?

For the unclamping of the main chuck, this is required for doing a bar pull operation, otherwise how would it pull the part out? The machine should not get an error unclamping the main chuck while the spindles are connected, otherwise you would not be able to do a part transfer between the spindles.

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

nicolas6DNFL — Thu, 16 Jan 2020 08:26:16 GMT

Hi Bob

The code doesnt match the operations in the fusion file

The sub should grab while spinning spin at 50 rpm (not G96S300), with a 25Deg offset

When pulling the bar it should spin at 500rpm

I would be expecting this

M135 (milling mode for C2)

M190 (un clamp c2)

G28H0. (ref C2 angle 0deg )

M35 (Milling C1)

M90 (un clamp C1)

G28H0. (ref C1)

G54G0C25. (clamp at 25deg)

M89 (clamp C1 axis)

M131 (ignore C2 check interlock )

M169 (c2 chuck open)

G97S50M204 (M204 sync c1 & c2 50 rpm)

G0B10. ( move C2 closer to part G0 move)

G1 B-10.25 F1000.

M168 (c2 chuck close)

G97S500M204 (M204 sync c1 & c2 500 rpm)

M69 (UNCLAMP MAIN CHUCK)

B18. F1000. (BAR PULL)

M68 (CLAMP MAIN CHUCK)

Then part where the first line should be the spindle set speed

G96 S200 M214 P11 (PHASE SYNCHRONIZATION)

I played around with the options and if you select a constant RPM speed not surface speed the post gives you an

Error: A spindle start block cannot be output while the spindles are synchronized.

Are you the author of the post, I'm happy to help work on this if you are ?

Thanks

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

nicolas6DNFL — Sat, 18 Jan 2020 06:03:01 GMT

I've started work on trying to fix this Post and I am running into issues, the variable

cycle.spindleOrientation doesn't exist, when it should map to this.

It doesn't come up in the tooltip help in VS Code and always maps to 0 if I include anyway.

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

bob.schultz — Sun, 19 Jan 2020 16:58:17 GMT

Thanks for you offer to work with us on fine tuning the part transfer logic. The part transfer code in the post reflects work done with different users when creating the post and cannot be changed in the stock post, since it would adversely affect customers currently using the post. For the spindle speed issues, the post is designed to use the spindle mode/speed/direction from the cutoff operation so that it does not change after/during the part transfer and part cutoff. I realize that not everyone utilizes the same procedures for part transfers, either by preference or machine capabilities, so in these cases it does require that the post be modified.

Here are the modifications that I made to get your desired output. For me, I did not have a problem with cycle.spindleOrientation, please try these changes and see if it is working for you. I did not add comments to all of the blocks output for the transfer operations, but you can do this by adding formatComment("comment") style code to the appropriate writeBlock calls.

First, at the top of the post add the following line.

// synchronized spindle start parameters
var SYNC_ERROR = 0;
var SYNC_UNCLAMP = 1;
var SYNC_SPEED = 2;
var SYNC_DEFAULT = 3;

And modify the following line.

var syncStartMethod = SYNC_DEFAULT; // method used to output spindle block when they are already synched/connected

In the onCycle function, comment out the following code.

      writeBlock(feedMode, gPlaneModal.format(18)/*, cAxisEngageModal.format(getCode("DISABLE_C_AXIS", getSpindle(PART)))*/);
      // writeBlock(mFormat.format(getCode("DISABLE_C_AXIS", getSecondarySpindle())));

In the "secondary-spindle-return" case in the onCycle function, add the following code. You can comment out the onDwell calls also if you like.

      // Transfer part to secondary spindle
      if (cycle.unclampMode != "keep-clamped") {
        secondaryPull = feedDis != 0;
        secondaryHome = true;
      } else {
        // pull part only (when offset!=0), Return secondary spindle to home (when offset=0)
        secondaryPull = feedDis != 0;
        secondaryHome = !secondaryPull;
      }
      
      var transferCodes = getSpindleTransferCodes(transferType);
      var code = getCode("SPINDLE_SYNCHRONIZATION_SPEED", getSecondarySpindle());
      if (!transferCodes.spindleDirection) {
        code += 1;
      }
      gSpindleModeModal.reset();
      writeBlock(
        gSpindleModeModal.format(getCode("CONSTANT_SURFACE_SPEED_OFF", getSpindle(PART))),
        sOutput.format(cycle.spindleSpeed),
        mFormat.format(code),
        formatComment("SPEED SYNCHRONIZATION")
      );

      // writeBlock(mFormat.format(getCode("INTERLOCK_BYPASS", getSecondarySpindle())));
...
...
      } else {
        clampChuck(getSpindle(PART), CLAMP);
        onDwell(cycle.dwell);
        // writeBlock(mFormat.format(getCode("COOLANT_THROUGH_TOOL_OFF", getSecondarySpindle())));
        // mInterferModal.reset();
        // writeBlock(mInterferModal.format(getCode("INTERFERENCE_CHECK_OFF", getSpindle(PART))));
      }
      machineState.stockTransferIsActive = true;
      break;

And finally, replace the code in the "secondary-spindle-grab" section with the following logic.

    case "secondary-spindle-grab":
      if (currentSection.partCatcher) {
        engagePartCatcher(true);
      }
      var transferCodes = getSpindleTransferCodes(transferType);
      writeBlock(mFormat.format(getCode("ENABLE_C_AXIS", getSecondarySpindle())));
      writeBlock(mFormat.format(getCode("UNLOCK_MULTI_AXIS", getSecondarySpindle())));
      writeBlock(gFormat.format(28), "H" + abcFormat.format(0)); // unwind
      writeBlock(mFormat.format(getCode("ENABLE_C_AXIS", getSpindle(PART))));
      writeBlock(mFormat.format(getCode("UNLOCK_MULTI_AXIS", getSpindle(PART))));
      writeBlock(gFormat.format(28), "H" + abcFormat.format(0)); // unwind
      writeBlock(gFormat.format(54), gFormat.format(0), "C" + abcFormat.format(cycle.spindleOrientation));
      writeBlock(mFormat.format(getCode("LOCK_MULTI_AXIS", getSpindle(PART))));
      writeBlock(mFormat.format(getCode("INTERLOCK_BYPASS", getSecondarySpindle())), formatComment("INTERLOCK BYPASS"));
      clampChuck(getSecondarySpindle(), UNCLAMP);
      gSpindleModeModal.reset();
      var code = getCode("SPINDLE_SYNCHRONIZATION_SPEED", getSecondarySpindle());
      if (!transferCodes.spindleDirection) {
        code += 1;
      }
      writeBlock(
        gSpindleModeModal.format(getCode("CONSTANT_SURFACE_SPEED_OFF", getSpindle(PART))),
        sOutput.format(cycle.spindleSpeed),
        mFormat.format(code),
        formatComment("SPEED SYNCHRONIZATION")
      );
      lastSpindleMode = SPINDLE_CONSTANT_SPINDLE_SPEED;
      gMotionModal.reset();
      moveSubSpindle(RAPID, cycle.feedPosition, 0, cycle.useMachineFrame, "", true);
      moveSubSpindle(FEED, cycle.chuckPosition, cycle.feedrate, cycle.useMachineFrame, "", true);
      clampChuck(getSecondarySpindle(), CLAMP);
      machineState.stockTransferIsActive = true;
      break;

These changes should get you the sample output that you provided. Let me know if you have any questions.

Thanks

Re: Doosan Mill/Turn Post version 42585 will crash with synced spindles

nicolas6DNFL — Tue, 21 Jan 2020 11:25:36 GMT

Hi Bob

I have been away for the last couple days but I edited the post to map the fusion GUI options.

I got the cycle.spindleOrientation working also, my stupid mistake

If you set an angle during chucking it will chuck at that angle, other wise it will sync the spindles and rotate

I have also added a custom negative Y range in the settings as otherwise the Y axis is useless on the Lynx Machine when doing X/Y milling. This is because the Y min is 0 but when you add the offset of a milling head in X you actually add Y offset since it's a compound angle and your Y can actually hit greater -ve values, making milling usefull.

Unless you can tell the post this, it defaults to X/C milling all the time !

I'm going to run some tests on a job we need to run, and I'll also post it here if anyone wants it

Not sure if there is a git repo for these somewhere or something.

Thanks