In case anybody else is having this issue and their Duet is buried inside their printer where the SD card isn't accessible, you can create the directory from the Web UI by navigating to this URL: (Replace <DuetIP>
with the IP address of your duet)
http://<DuetIP>/rr_mkdir?dir=0%3A%2Ffilaments
Best posts made by yngndrw
-
RE: Error: Failed to create directory 0:/filaments/PLA
-
RE: RepRapFirmware road map Q1 2021
Very excited about the input shaping, especially after this video was released yesterday:
https://www.youtube.com/watch?v=6JBIEJan6zs&ab_channel=Vez3D -
RE: PrintEye; simple information panel for Duet boards.
@EasyTarget No worries, I'm sorry my message came across badly - It was probably not the best judgement for my first post on here in years to be a "have you considered X hardware" post. The issue only came to mind because I'd recently used an RP2040 (Specifically the W5500-EVB-Pico, a fantastic board if you need ethernet in a project) on a commercial project and hit the memory limit a number of times. At the end of the day the "right" thing to use is whatever you're comfortable with - It's all personal preference as long as you're aware of the limits and trade-offs.
-
RE: CNC-Specific Board
@o_lampe
Yes that's what I meant about not allowing remote resetting. You should need to physically return to the machine in order to reset and re-arm the machine.I think from a software point of view, this means that there should be slightly different terminology within the software. You can trigger the emergency stop and you can clear the fault from the software's point of view, but you cannot reset the emergency stop from there. From a documentation point of view, I'd try to push people down the route of using a real safety relay with redundancy and dual channel emergency stops.
I'd recommend #5 from my list above for your machine if your drivers support it, it should be the easiest to configure and it will prevent burning out motors / drives and destroying mechanical parts if the same thing happens again. (Or at least, it will in some scenarios!)
-
RE: Warning to users of servomotors!
Back in the days of GeckoDrive, they documented a simple circuit to clamp the supply in situations like this:
https://www.geckodrive.com/support/returned-energy-dump.htmlI'm thinking that a sufficiently sized TVS diode would would resolve the issue, although given that the JMC iHSV servos are rated up to 50V with 36V nominal, you're probably better running them at 36V separate from the Duet anyway as suggested above.
-
RE: Soldering/Hot Air Station - What are these for?
@richardmckenna To me it looks like a stand. If you rotate the wire part 180 degrees, put the screw through the narrow part and into the hold on the bar, you end up with a sort of tuning fork shape.
That's my guess anyway. Did it not come with a manual or some pictures of it in its assembled state?
Edit:
Just found this which shows it assembled:
Not sure what it's for though, maybe it's for poking people who interrupt your soldering session?
-
RE: PrintEye; simple information panel for Duet boards.
@EasyTarget You may want to consider an ESP32 over the RP2040. I adore the RP2040 and use it whenever I can but I often find that for projects which involve a lot of JSON, the memory limit becomes an issue. The ESP32 has the advantage that it can use external memory, whilst still being a modern dual-core microcontroller.
-
RE: PrintEye; simple information panel for Duet boards.
@EasyTarget I'm just advising that memory might become an issue for the JSON parsing, that's all. I did say I adore the RP2040, it's my go-to when memory isn't an issue - They all have their place. I'll keep to myself next time, sorry to bother you.
-
RE: PrintEye; simple information panel for Duet boards.
@dc42 said in PrintEye; simple information panel for Duet boards.:
@yngndrw said in PrintEye; simple information panel for Duet boards.:
I'm just advising that memory might become an issue for the JSON parsing, that's all
You might like to look at the PanelDueFirmware code on github. It uses a Json parser that uses minimal RAM.
Ohh I didn't notice that library, I'll have to give JSMN a try in my own projects! Thanks.
Latest posts made by yngndrw
-
RE: PrintEye; simple information panel for Duet boards.
@dc42 said in PrintEye; simple information panel for Duet boards.:
@yngndrw said in PrintEye; simple information panel for Duet boards.:
I'm just advising that memory might become an issue for the JSON parsing, that's all
You might like to look at the PanelDueFirmware code on github. It uses a Json parser that uses minimal RAM.
Ohh I didn't notice that library, I'll have to give JSMN a try in my own projects! Thanks.
-
RE: PrintEye; simple information panel for Duet boards.
@EasyTarget No worries, I'm sorry my message came across badly - It was probably not the best judgement for my first post on here in years to be a "have you considered X hardware" post. The issue only came to mind because I'd recently used an RP2040 (Specifically the W5500-EVB-Pico, a fantastic board if you need ethernet in a project) on a commercial project and hit the memory limit a number of times. At the end of the day the "right" thing to use is whatever you're comfortable with - It's all personal preference as long as you're aware of the limits and trade-offs.
-
RE: PrintEye; simple information panel for Duet boards.
@EasyTarget I'm just advising that memory might become an issue for the JSON parsing, that's all. I did say I adore the RP2040, it's my go-to when memory isn't an issue - They all have their place. I'll keep to myself next time, sorry to bother you.
-
RE: PrintEye; simple information panel for Duet boards.
@EasyTarget You may want to consider an ESP32 over the RP2040. I adore the RP2040 and use it whenever I can but I often find that for projects which involve a lot of JSON, the memory limit becomes an issue. The ESP32 has the advantage that it can use external memory, whilst still being a modern dual-core microcontroller.
-
1XD with encoder inputs (Homing based on incremental encoders)
Hello,
The 1XD board is a great step towards proper servo drives for CNC usage. With a proper AC servo which has closed loop control between the motor and the driver, end-to-end closed loop control isn't really needed especially if the error/fault output of the servo drive is used. There is however a second use for encoder inputs - Homing.
Proper servo drives often have buffered encoder outputs, which are the full complement of encoder signals including the index. If a "course" homing switch is included on the axis to get within one motor revolution of the final home location, the final homing can be completed using the encoder by allowing it to continue rotating in a given direction until the index signal is raised. This is far more repeatable than a homing switch (Subject to backlash) and operates with the same resolution of the servo motor.
Obviously this also puts in the ground-work for end-to-end closed loop control with external drivers if that's implemented.
So my proposal is to build another version of the 1XD with some more I/O:
- 3x differential driver outputs: Step/Direction/Enable [As it currently has]
- 1x high-current brake output [As it currently has]
- 3x differential encoder inputs: A/B/I
- 1x differential error/fault input
- 2x single-ended endstop inputs (Can be GPIO) [As it currently has]
See page #57 for an example encoder output from a servo drive:
https://www.applied-motion.com/sites/default/files/hardware-manuals/SV200_AC_Hardware_Manual_920-0096H.pdfThe other option of course is something like EtherCat, but that's a whole separate topic.
Thanks,
-Andrew. -
RE: CNC-Specific Board
@tenaja I've not seen those before, they look like a very interesting concept.
I think for this usage they will take up too much space and cost too much, but I do wonder if the concept could be used - Maybe add-on boards that can adapt banks of outputs to meet various requirements. For example you might want relay outputs, or open collector outputs, 5V outputs, 24V outputs.
I'm trying to balance this with the space usage because I think for the people who are likely to use it (For "desktop" to medium CNC machines essentially), they are likely to have limited space in their control enclosures. For myself, I need to fit everything in a steel enclosure which will slide out beneath an Ikea Lack table which gives me about 500x400x200mm - VFD and all. I think I can get the size down to about 100x50mm or less.
I've also been considering the selection of some of the connectors. I've chosen a right angled RJ45 & RJ11 connector with the release tab on the top, a "flip up" SD card holder which could be mounted away from the edge of the board and a "vertical" micro USB connector which again can be mounted away from the edge of the board. I might even do away with the reset button / external reset input as I don't think it's really required for this application. On the flip side, I'm going to add a lot of status LEDs for every input and output for example.
I typically use EasyEDA as I really like their library integration and I'd probably use JLCPCB's assembly service, but sadly some of the components (The processor for example) do not seem to have footprints right now. I've tried all of the PCB / Schematic software packages and I'm yet to find one I'm really happy with.
https://lcsc.com/product-detail/Ethernet-Connectors-Modular-Connectors-RJ45-RJ11_CONNFLY-Elec-DS1133-S60APX_C77858.html
https://lcsc.com/product-detail/Ethernet-Connectors-Modular-Connectors-RJ45-RJ11_UDE-Corp-S22-ZZ-0019_C711502.html
https://lcsc.com/product-detail/USB-Connectors_Korean-Hroparts-Elec-U-D-M5DD-W-1_C145795.html
https://lcsc.com/product-detail/Card-Sockets-Connectors_MOLEX-472192001_C164170.html -
RE: CNC-Specific Board
@tenaja Yea that was the main aim really, to replace a ~£300 200x100mm Duet 3 Mini 5+ / 4x Duet 3 Expansion 1XD setup with a ~£150 100x100mm board, while still supporting the latest from the Duet platform. (I.e. CAN)
Another goal is to have something which properly integrates with a safety relay, I see so many people mess up their emergency stop wiring both with and without a safety relay. Something is bound to go wrong if somebody doesn't step in so that's why I'm going to add first class support. (I plan to make it difficult to cut corners, I'm only going to provide diagrams showing how to use it with the safety circuits.)
I've updated the first post with the latest.
-
RE: CNC-Specific Board
@tenaja The main goals are both a cost reduction and a reduction in the overall size for those using separate drivers. (The Duet 3 Expansion 1XD is nice, but it's simply way too large and expensive for a single axis - If you want to drive four axes you're nearly doubling both the price and space required)
Sorry I forgot to update the original post with the latest specs, after @o_lampe's comments I was planning on dropping the higher voltage input altogether and just accepting a regulated 5V input which greatly simplifies the board and means that there's no limitations in motor supply voltage. For my own machine I plan on using a Mean Well HRPG-600-36 (36V @ 17.5A / 600W) for the brushless servos and a Mean Well RD-65B (5V @ 8A / 24V @ 3A / 65W) for both the controller and the safety circuit.
My latest considerations are around whether or not to make this a stand-alone board or build it around the Raspberry Pi CM4 SBC. I personally really like the way I interact with my Duet 2 on my 3D printer so I wasn't originally planning on going down the SBC route due to the added complexity and space usage, but MPGs complicate that somewhat. There is a thread (https://forum.duet3d.com/topic/11389/cnc-style-pendant/150) about building a serial MPG which interfaces with the standalone Duet boards so if gives smooth jogging then I probably won't bother with the SBC route, but if I were going to go down the SBC route I think I'd rather go all-in with the board and accept (Require) a compute module directly - This would mean the removal of the SD card and the ethernet controller from the Duet processor. I'm not sure I see enough benefit for the extra cost, complexity and space though. ( @dc42: Are there any plans to drop support for the "standalone" Duet mode, or will the SBC always be optional?)
-
RE: CNC-Specific Board
@o_lampe
Yes that's what I meant about not allowing remote resetting. You should need to physically return to the machine in order to reset and re-arm the machine.I think from a software point of view, this means that there should be slightly different terminology within the software. You can trigger the emergency stop and you can clear the fault from the software's point of view, but you cannot reset the emergency stop from there. From a documentation point of view, I'd try to push people down the route of using a real safety relay with redundancy and dual channel emergency stops.
I'd recommend #5 from my list above for your machine if your drivers support it, it should be the easiest to configure and it will prevent burning out motors / drives and destroying mechanical parts if the same thing happens again. (Or at least, it will in some scenarios!)
-
RE: CNC-Specific Board
@o_lampe
Thank you for your responses. I've made a couple of changes to the original list (In square brackets) after sleeping on it, the main things are the removal of PS_ON and the removal of the Vin output for the 0-10V converter as this is usually powered directly from the VFD. I've removed PS_ON from the list because it somewhat conflicts with the concept of a safety relay managing the power supply and reset conditions - We're talking about a CNC machine rather than a 3D printer so being able to remotely turn it on or reset an emergency stop condition is a no-no.[A1] This leads on to your first question, why use a 24V input. It really comes down to convenience as 24V is very common in industrial systems and is also the voltage of choice for most safety relays. Having said that I think you're right that just using an external 5V power supply isn't an issue and probably fits a CNC application better, where DIN mounted power supplies are both plentiful and cheap. It would also make it harder for a user to share a power supply between the safety system and the controller, which I think is best to avoid.
[A2] These would just be conventional inputs, mapped as required. The 30V tolerance should allow for 24V sensors with PNP outputs, while also allowing for just about any other configuration. You could also use an external board via CAN. I'll try and add more inputs seems as there are no-longer any thermistor inputs so there should be plenty of spare pins.
[A3] I don't actually like fully closed loop setups, let me explain. I think they have their place where backlash is a major issue, but if you're going down the rabbit hole of using AC servos with proper drivers (Using velocity or torque control, not step / direction) and have proper linear scales on your machine (Motor-mounted encoders are pointless for full closed loop control as they cannot prevent any backlash), a budget version of the Duet 3 controller is probably not right for you. In this scenario you'd probably be looking at something like the Centroid Oak controller, which costs around $1250 - Small change considering the other costs.
This brings me onto these partially closed loop setups, I like these setups. (The CNC I'm building has JMC 180W brushless servos) You get the maximum performance from the motor without any instability and it draws the line where I think it should - You should be able to trust the controller to motor driver communication. If you're losing steps due to interference for example, you're better served fixing your wiring. The only real disadvantage (Aside from the backlash as mentioned above, for machines in this category anti-backlash mechanics are the solution) from not having a fully closed loop setup is that you have to tune an additional positional PID loop, but that's not a bit issue.
As for your dual Y axis issue, I think there's a couple of questions to be asked and possibly some other solutions which are a better fit:
- Why did your motor stall in the first place? Is it running too close to the edge of its limits or did you have issues with midband-instability?
- Why did the second motor have enough torque to cause an issue if the first motor stalled? Is one side binding or is the frame misaligned?
- If your motors have enough torque to destroy your frame, the frame isn't strong enough. This would have caused machining issues so the frame probably needs to be stronger.
- If the motors are still too strong, it may be worth setting a torque limit if you can depending on the driver you're using. It may be that you need a powerful motor for higher speeds, but at lower speeds they are providing too much torque. A torque limit could flatten this to an acceptable level across the whole speed range.
- The motor drivers should output a fault signal which should be used to stop the machine, preventing damage. The fault could be that too much torque is being demanded, the motor is too far from its commanded position (Either a tuning issue or a faulty encoder causing runaway?) or that the driver or motor has overheated.