Posts made by Generic Default

@dc42 This list below isn't everything we added, but most of what I can think of off the top of my head:

1. Added GUI for monitoring spindles (RPM, Torque, Encoder Angle, Power, Load Meter) (customizable)
   ---1) (a) Full system for monitoring feedback from servo drivers and VFDs in real time
2. Added GUI for changing the parameters of the tools in the ATC magazine and turrets (pictures too)
3. Added X/Y/Z/A/B/C/U/V/W/D axis position display on the screen (customizable)
4. Added conversational programming menu with common functions - creates job files in a text editor
5. Added CNC specific M codes and G codes
   ---5)(a) Rigid tapping, Drilling cycles, Lathe threading, helical boring, M19 spindle orient, M3 M4 M5, etc.
6. Added useful on screen M codes with GUI buttons to activate (coolant, air blast, auger motor, etc)
7. Added redundant rotary axis gearbox system - lets the machine engage a gearbox and use a separate servo to drive it. We use this to switch from belt drive with big servos to gearbox drive through a harmonic gear for high accuracy and torque.
8. Machine RGY status light and E stop system, along with servo status menu
9. Auto-stop when a servo overloads or faults.

There are quite a few other things I'm not remembering off the top of my head, but we added a ton of stuff to make the Duet system run a 12 servo, 8 axis mill turn machine. This is the same one from the other thread. Integrating all this stuff into the newer 3.5 firmware and future versions would benefit everyone, even if few CNC machines require all the functions we built.

@dc42 We re-added the implicit G2/G3 in our version of 3.3 firmware, because the Fanuc standard post processor that a huge percentage of CNC machines run on does G0, G1, G2, and G3 commands in the code it spits out.

In my test, the presence of a G2 G3 at the beginning did not change the result, only the feedrate parameter changed it.

We're trying to merge our CNC functions into the 3.5 firmware.

@dc42 Duet 6HC with 3.3 firmware. 400 steps/mm

@dc42 We tested more today, and narrowed down the problem.
First, we changed the parameter "MinArcSegmentLength" to 0.02 as you recommended. It didn't change anything.

I made a basic hand written program to run the machine in a G3 arc. I found that it will run the arc smoothly at certain feedrates, but not at other feedrates.

The program;
G0 X200 Y0 Z150
G3 F5000 X200 Y0 I-50 J0

For example, at 2000 mm/min, the machine ran in a smooth circle, as expected.
Running the program many times confirmed that this worked perfectly every time.

Here are the results;
2000 - normal
5000 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)
6000 - normal
8000 - normal
9000 - normal
1000 - normal
900 - normal
920 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)

The only conclusion that I can draw is that the feedrate parameter causes a stall during an arc move at certain feedrates, but not others. The feedrates are repeatable - I.E. it's not random. Running at 5000 will fail every time and running at 6000 will work every time. I should note that the "pause" is an abrupt stop, not a smooth deceleration. It stops then starts again a fraction of a second later.

I suspect there is some parsing error in the motion control that causes a temporary stop if the feedrate has a certain bit in it.... I don't know what though.

More exhaustive testing:
5000 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)
5001 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)
5002 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)
5003 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)
5004 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)
5005 - pauses at the Y direction change reversal point (Ymax and Ymin on the circle)
5006 - normal
5007 - normal
5008 - normal
5009 - normal
5010 - normal

VIDEO OF THE TEST
https://youtu.be/5JYNb3g_WhA

@tenaja The Duet uses the stepper motor drivers directly on the board - we took the step/dir outputs from these and use them to control full sized AC servos from Delta electronics - exactly like a Fanuc or equivalent AC servo. They have 22, 23, or 24 bit encoders on them, which are no absolute, but act like absolute after finding the index pulse.

We are likely to switch to Absolute encoders in the future to avoid homing. For now, when the machine is turned on, it needs to be homed like a 3d printer, this takes about 30 seconds. It doesn't use limit switches to do this, rather it just goes until the servo driver detects a stall, then backs off to the nearest index pulse. This gives perfect repeatability to the micron.

Yes, it has functions like M19 spindle orient, M8 coolant, G72 threading, G84 rigid tapping, all that. It also has a 24 tool ATC side mounted with accessibility through the operator door.

As far as backlash, we are using Hiwin ballscrews and a typical angular contact setup. The backlash is under 1 micron, so we don't need to adjust it. We did create a backlash firmware feature (which is now unnecessary in Duet firmware 3.5+) but the mechanical backlash of each axis is negligible so we just set it to zero.

Here's the calibration video, showing the accuracy. (is there a way to make the video show up as embedded?)

https://youtu.be/78-dqxRgQ-o

@fishgrog Actually, it's almost the same as far as function and operations go. The MT900 just has a larger work envelope and side mount ATC. The user interface is almost identical. If you run the exact same program for turning and milling on the two different machines, they will make the same part. The MT210 uses the previous version of the same transfer board for the servos, and other than differences in the Arduino firmware and config files, they are basically the same thing.

The MT900 has much larger cast iron structures and a big enclosure of course. They look very different but do the same thing.

@dc42

Here's up close.

The purpose of the transfer board is to take the step/dir signals from the Duet and pass them on to the servo drivers. It has all the connectors for the servo drivers (see the RJ jacks for each servo driver) with both digital and analog communication, and at the top of this transfer board there's an Arduino due in the open rectangular spot (not mounted in this picture). The transfer board also hosts a lot of the I/O pins and has rugged industrial connectors.

One concern I have with the Duet design is that we have to manually solder wires to each step/dir output on the back of the Duet board and expansion. I wish it had regular 0.1mm pins. A big concern has always been missed steps due to noise, I believe we ended up putting opto-isolators or digital isolators on every one of these to prevent noise on the step/dir stuff.

We are currently on RepRap firmware 3.3 and an older build of the DWC. Our code projects have become much more complex than I'd like. In the beginning, I wanted to mount the Duet on standoffs directly on the big transfer board, but the Duet CAN bus had protocol problems when we tried to integrate it, so we ended up using an Arduino as an intermediary, but of course this made everything more complex.

I'd be open to sharing the whole transfer board project as open source if it could be managed better than we can do. Right now I am a bit hesitant of putting it all online as open source because I think it needs a team of programmers to really understand and integrate, if I just dump the code online I doubt anyone could make use of it.

This is the 3rd iteration of the transfer board design that we did a formal PCB run with. We have 5 of these with components soldered and 5 more without. I'll try to post a video of the DWC modifications we made as well; they are useful for CNC but not 3d printing.

Hi everyone!
Some people may remember the SwissMak project from like 5 years ago. This is the culmination of that project.

It's a 12 servo, 8 axis mill turn machining center that runs on the Duet 3 with an expansion board and a custom transfer board we made that allows the Duet to control full sized industrial AC servos.

I have a lot of photos and videos but the file size limit of 4 mb here prevents the cool GIFs from being uploaded. I'll be posting content to YouTube and my website in the future. I'm not trying to advertise this machine here because it's prohibitively expensive for hobbyists and 3d printer people. My original goal of building super low cost machines never panned out, rather than producing a 4-5 thousand dollar mill turn for hobby level machining with stepper motors, we ended up building a $25,000 machine for job shops and companies that do prototyping which we call the MT-210, and the photos above are of the newest model, the MT-900. Both the MT-210 and MT-900 run on the Duet 3 board with an expansion board (they need like 10-12 servos!). We have heavily modified the RepRap firmware and the DWC to run Gcode from CAM software intended for CNC machines. I would like to contribute to the open source side by merging our additional G-codes and M-codes and the system we designed that allows the DWC to take feedback from the servo drivers and display it on the DWC menu in real time. We also need to update to 3.5 firmware because the 3.3 firmware has some bugs that negatively affect us. Our attempt at branching the RepRap/DWC code bases have been messy and inefficient, but we do have a working, functional system.

We built two of these for the TIMTOS machine tool trade show which is coming up on March 6-11 of 2023. We have entered this in a competition for most innovative machine, and the big thing we're emphasizing is the Duet 3 control based system. Since the CNC manufacturers aren't used to seeing 3d printer controllers running full sizes CNC machines, we should stand out a bit. I'll post here with the results after next week, hopefully we win!

I think this is probably the most complex and expensive machine to be built with the Duet boards. My biggest long running concern is that every time we update the RepRap firmware, we have to re-integrate all our custom CNC code and debug. 3.5 firmware is very different so we are going to have to spend a ton of time redoing it. We really need some of the new features, especially things that make 5 axis programs run better, and other CNC specific processes that we haven't programmed yet.

@dc42 We are currently communicating with the Odrive by UART through an intermediary Arduino Due. The data rate is slow and inconsistent; we are trying to read incremental encoder data (angle) from the Odrive by sending the string back to the Arduino from the ODrive, and then from the Arduino to the Duet 3.

We also have everything connected and working with a USB hub.

I wasn't aware if a second CAN on the Duet, we were studying the CAN FD to see if it can read data from a standard CAN 2.0.

We have also made significant changes the DWC to allow for 10 axis control, where you can drag a simulated machine axis on the screen and the real machine will move to that position.

I think if we are not able to get the CAN or an I/O to work for step/dir, we may just void the warranty on one of the expansion boards that is connected (which gives A/B/C steppers) and read those stepper signals while turning off the drivers, such that the step/dir signal will control the Odrive servo, but the actual stepper motors connected to A/B/C will not move.

I'll try to get a video or pictures of our system and modified DWC to post here later.

I know there is the 1xd board available for external stepper drivers, but we are looking at an unconventional system that already has the Duet 3 main, 2 3HC expansion boards, and several other boards all communicating. We just need 3.3v pins anywhere on the Duet system that can flicker a logic 1/0 and be configured like a stepper.

Can any developers explain why none of the I/Os can be configured as a step/dir with M590? We are also trying to communicate directly with the external Odrive controller by CAN, but the CAN FD is different and it's slowing us down.

We can make low level pin changes to the firmware if necessary.

Hey,

We build 10 axis CNC mill-turn machines driven by the Duet 3 board + expansions as the main control board. Our system also has an Arduino due based transfer board for extra hardware breakouts, and also controls several powerful servos by ODrive boards. All of our systems are integrated and our machines work.

The main problem we're having now is that there is no CANNED CYCLE functionality in most 3d printer firmware. These are the modal Gcodes like G83 (peck drilling cycle) which stay active until they are cancelled.

We have a full time software developer working on this system, and we are just now getting to the point of implementing these industry standard canned cycle Gcodes into our system. This means some major changes to the Gcode interpreter must be done to support all the new codes.

Can anyone point me in the right direction if anybody else has already started on canned cycles, or has a working version of the firmware which supports them better?

If not, we would like to contribute our code once it's done so that everyone can use canned cycles in their own cnc machines. Currently the Gcodes between G60 and G90 are pretty much unused by 3d printers, and we would just be filling out the one part of the interpreter than goes case by case for each Gcode and Mcode.

Thanks!