PLS OUR LORD DC42 I NEED HELP
Don’t want to hurt your religious feelings, but when running Klipper, it looks like you’re in the wrong temple: this forum is dedicated to RRF.
PLS OUR LORD DC42 I NEED HELP
Don’t want to hurt your religious feelings, but when running Klipper, it looks like you’re in the wrong temple: this forum is dedicated to RRF.
@amjm22 When opening your config.g in a browser, it is an unreadable string. In the forum editor, you can use the "</>" tag to create a box to which you then can paste the config like this:
; Configuration file for RepRapFirmware on Duet 3 Mini 5+ WiFi
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.5.0-rc.3+2 on Wed Mar 20 2024 06:10:00 GMT-0400 (Eastern Daylight Time)
; General
M550 P"TheMachine" ; set hostname
; Network
M586 P0 S1 ; configure HTTP
M586 P1 S1 ; configure FTP
M586 P2 S1 ; configure Telnet
; LED Strips
M950 E0 C"io1.out" T1 ; configure LED strip #0
; Smart Drivers
M569 P0.0 S1 D2 ; driver 0.0 goes forwards (X axis)
M569 P0.1 S1 D2 ; driver 0.1 goes forwards (Y axis)
M569 P0.2 S1 D2 ; driver 0.2 goes forwards (Z axis)
M569 P0.3 S1 D2 ; driver 0.3 goes forwards (extruder 0)
; Motor Idle Current Reduction
M906 I30 ; set motor current idle factor
M84 S30 ; set motor current idle timeout
; Axes
M584 X0.0 Y0.1 Z0.2 ; set axis mapping
M350 X16 Y16 Z16 I1 ; configure microstepping with interpolation
M906 X800 Y800 Z800 ; set axis driver currents
M92 X80 Y80 Z80 ; configure steps per mm
M566 X1200 Y1200 Z1200 ; set maximum instantaneous speed changes (mm/min)
M203 X18000 Y18000 Z18000 ; set maximum speeds (mm/min)
M201 X1000 Y1000 Z1000 ; set accelerations (mm/s^2)
; Extruders
M584 E0.3 ; set extruder mapping
M350 E16 I1 ; configure microstepping with interpolation
M906 E700 ; set extruder driver currents
M92 E690 ; configure steps per mm
M566 E1800 ; set maximum instantaneous speed changes (mm/min)
M203 E3600 ; set maximum speeds (mm/min)
M201 E1000 ; set accelerations (mm/s^2)
; Kinematics
M665 R150 L360.24 B140 H520 ; set delta radius, diagonal rod length, printable radius and homed height
M208 Z0 S1 ; set minimum Z
M666 X0 Y0 Z0 A0 B0 ; endstop adjustments and XY tilt, can be determined using auto calibration as well
; Probes
M558 K0 P5 C"nil+io4.out" H5 F120 T6000 ; configure digital probe via slot #0
M558 H30 ;*** Remove this line after delta calibration has been done and new delta parameters have been saved
G31 P500 X0 Y0 Z0.7 ; set Z probe trigger value, offset and trigger height
; Endstops
M574 X2 P"io3.in" S1 ; configure X axis endstop
M574 Y2 P"io5.in" S1 ; configure Y axis endstop
M574 Z2 P"io6.in" S1 ; configure Z axis endstop
; Mesh Bed Compensation
M557 R135 S40:40 ; define grid for mesh bed compensation
; Heaters
M308 S0 P"temp0" Y"thermistor" T100000 B3950 C7.06e-8; configure sensor 0 as thermistor on pin temp1
M950 H0 C"out0" T0 ; create bed heater output on out1 and map it to sensor 0
M307 H0 B0 S1.00 ; disable bang-bang mode for the bed heater and set PWM limit
M140 H0 ; map heated bed to heater 0
M143 H0 S145 ; set temperature limit for heater 0 to 145C
M308 S1 P"temp1" Y"thermistor" T100000 B4725 6e-8 ; configure sensor #0
M308 S1 P"temp1" Y"thermistor" A"Nozzle" T100000 B4725 ; configure sensor 1 as thermistor on pin temp2
M950 H1 C"out1" T1 ; create nozzle heater output on out2 and map it to sensor 1
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit
; Fans
M950 F0 C"out6" ; create fan #0
M106 P0 S0 L0 X1 B0.1 ; configure fan #0
M950 F1 C"out5" ; create fan #1
M106 P1 S0 B0.1 H1 T45 ; configure fan #1
; Tools
M563 P0 D0 H1 F0 ; create tool #0
M568 P0 R0 S0 ; set initial tool #0 active and standby temperatures to 0C
; Miscellaneous
T0 ; select first tool
The error message hints at some wrong port assignment with M950
, in this case, I think you assign IO_1 twice:
M950 E0 C"io1.out" T1 ; configure LED strip #0
M950 H1 C"out1" T1 ; create nozzle heater output on out2 and map it to sensor 1
BTW, in both cases, the comment is misleading, it doesn't match the effective IO-ports
Conceptually to treat the physical 0,0 as 0,-10 is broken. There should be a way to shift the origin so that 0,0 is physically 0,0.
There’s nothing broken at all. Aside from mixing the physical coordinates of your printer with the rather „logical“ origin of your workspace, you misunderstand what M208 does. It allows me to even define the center of my bed as X0 Y0. @T3P3Tony is exactly to the point - now it’s your turn to understand M208. I recommend to study the reference manual, I.e. the GCode dictionary. Oh, and forget G10 in this context (or better look it up, too). If questions remain, post your config.g and indicate where your endstops are located.
@o_lampe said in Fun Fact .. you can use GPT Chat For:
The next logical thing to do: Remove the config-tool and add a link to GPT instead
Why stop there? What about a Duet controller with AI and natural language IO? Reportedly, @DC42 already has a working prototype of the Duet AI5 on his desk - the last hurdle being a mysterious error message: „I’m sorry Dave. I’m afraid I can’t do that“
@MaxGyver said in [3.5.0-rc.3] G30 probe point does not respect axis limits:
Everything after that should happen within these machine (soft) limits or not?
When you run milling instructions, i.e. during normal operation, there should be no need to exceed the work area, so it might be a good idea to limit the axes to that instead of the physical machine limits. I understand that you want to apply the machine limits to every command except of those „milling instructions“. As RRF doesn’t provide more than one set of boundaries, I propose to secure the out-of-bounds instructions by macros who can observe the machine limits. Of course, probing Z with G30
can still fail, but as @gloomyandy stated, you then will have to provide power-killing limit switches to protect the machine.
Having to know and remember all the cases where the axis can move out of bounds is kind of my problem.
That depends on which bounds you mean. Prior to homing all axes, there are no bounds at all - just mechanical limitations (who might cause damage on a powerful machine if it runs into these).
After homing, you set up a coordinate system related to the tool tip - you zero-in on a single point. In practice, the machine’s head tends to be more spacious, so you have to take various offsets into account. This can be cumbersome, especially with regards to the Z probe, but there’s no other way.
At this stage of the setup, the bounds define the physical range your tooltip can operate within - which might still include regions outside of the working area. That’s why you can further restrict axis movement with M208
. This working area should be safe in the sense that, while executing milling instructions, these will not exceed the limits.
During the setup process, this safety cannot exist - else, you would not be able to probe the limits. The same applies to tool changes: you will have to recalibrate your Z-height (which is inherently unsafe). For that reason, I suppose to enclose these potentially dangerous ops in carefully crafted macros.
@MaxGyver Where’s the problem? If you use G30
within your calibration process, they are embedded in scripts - when writing those scripts, you might possibly remember the permitted coordinate range. If not (or if you intend to enter probe points from the console), use a macro instead. This macro can clip any input to the working area constraints.
@Mythbear74 Better stay with your original thread on this issue and interact with the guys trying to assist in resolving the problem.
@soare0 Interesting connotation, thanks for the insight. My reservation against using the δαίμονας is more profane: it has the potential to bog down the MCU, interpreted scripts tend to use vast amounts of processor cycles - which is especially true for my venerable Duet 2 system.
You are using S3 just for overheating protection, and then put H3 it in fault state, wich makes H3 unusable.
Right, my S3 is just an auxiliary measure to limit the PTCs - these things tend to thermal runaways and are thus limited internally (240° in my case). Basically, I intended to reduce air flow inside the chamber to a minimum, so the small PTCs dissipate their heat mainly by means of a large aluminum sheet, the fans only have to remove some heat from between sheet and chamber wall. So, my system is well balanced (it just has to handle 300 W) and never reached the S3 limit.
In your case, the easiest solution I can imagine is to monitor your S3 in daemon.g. By this, you can overcome the flaw your rightfully spotted in my approach. And yes: your poetical jokes are welcome
Is there a timer driven intrerupt available on DUET boards, or such a thing
Back then with RRF 2.x, I had to configure a chamber heater composed of 2 PTCs, 4 fans, 2 thermistors sensing the PTCs and another 2 thermistors to monitor the temperatures at the top and bottom of the chamber. Just some entries to the config.g. Look: no macro script needed, no "interrupt" anywhere. Of course, the Gcodes were adjusted to work with the latest stable RRF (3.4.6).
; Setting up the chamber heater:
M308 S3 P"duex.e2temp" Y"thermistor" A"Chamber PTCs" T50000 ; sensor 3: direct thermistor on heater #3 (we use two parallel thermistors)
M308 S4 P"duex.e3temp" Y"thermistor" A"Chamber Top" ; sensor 4: chamber top sensor controls heater
M308 S5 P"duex.e4temp" Y"thermistor" A"Chamber Bottom" ; sensor 5: bottom sensor, just for info
M950 H3 C"duex.e2heat" T4 ; heater 3 is chamber heater, uses temp.-sensor 4
M307 H3 A11 C900 D30 B1 ; define heater model parameters manually
M141 H3 S-273.15 R0 ; heater 3: initially 0 degrees, off
; Adjust chamber heater fault detection:
M570 H3 P300 T25 ; allowed deviation before heater fault: < 300 secs, ± 25 degrees
; Connecting fans to the chamber heater:
M950 F3 C"duex.fan3"
M950 F4 C"duex.fan4"
M106 P3 L0.2 X0.7 T40:180 H3
M106 P4 L0.2 X0.7 T40:180 H3
; Protect chamber heaters against overheating:
M143 H3 T3 A2 C0 S150 ; shut-down heaters temporarily if exceeding 150 degrees (never happens, can be removed)
Your case involves less components, so you can simplify the setup.
Is this worthwhile to the community?
No. Many resellers exist primarily to minimise the cost of shipping, customs and taxes for the end customer. A global ranking across different economic areas would be worthless.
Others offer DUETs in connection with their own products - then, it's about the quality of their system integration, not about the controller itself. It makes no sense to award stars for this in the Duet forum.
When you need technical support, you inevitably arrive at this forum - here, you can already rate every single contribution.
Of course, there are a thousand reasons for dissatisfaction with a dealer, but without further explanation, a star rating says nothing at all. In such cases, it is better to write an e-mail to Duet3D. Depending on the assessment of the circumstances, they will take care of it.
@o_lampe I fully agree. Type ’42’ into the calculator - it will never return ’Douglas Adams’, the single reasonable answer I would accept.
Same here: If you don’t know the question, the AI can’t answer it. Having no clue whatsoever, and utterly missing ’Big Thought’, the poor OP even asked the AI to generate the question on its own. Well, the AI wasn’t that bad, in essence, it stated:
”We want to automate our major enterprise, look at my mixed bag treasury of ’something’, uh, no idea, c'mon and elaborate the blueprints - adhering to best practice, of course.”
Sounds like a lucrative job offer - lest the salary. Our admins removed an identical post asking for the required codework to be sent, but the OP simply reposted it a few days later, thus proving a rather limited understanding of social interaction.
Of course you were perfectly right with your ”Rant”, the OP is a gambler, always looking to reduce the wear of his precious brain cells to a minimum by putting the burden of thinking on others. Let's see how far he comes - be sure that, at some point, he'll smash into the wall of reality.
@Rackan-Mansour
I just used to it to save time writing comprehensive forum posts.
Dream on. Recall my reaction on that ”stupid AI chatter” as I called it? Read it again. I don't like you to waste my time on such dumb posts just to save a bit of your own.
I don't believe it is illegal anywhere.
Stupidity has always been free and available in vast quantities. And yes: it’s perfectly legal.
It is being used as an enhancement …
Right, AI amplifies the collective incompetence it has been trained with. So long, and thanks for the fish!
@Rackan-Mansour
I used Ai to create two different posts, based on the specifications i had, for the two different forums to get insight from each.
Thanks for the honest answer. You have just yourself to blame for my aggression, it's my natural reaction to stupid AI chatter. Take my good advice and better use your own device - the one between your ears.
I really have no base knowledge.
Great! I suggest to start with the RasPI. Attach a power supply, keyboard and screen. Then, play with it to explore the operating system. Tutorials can be found on the internet (but don't waste your time on YouTube). Get used to the PI's command line interface (CLI).
Next step is to attach the ultrasonic sensor. On the fly, you will learn a lot about the PI’s interfaces and how to deal with them. Pick one of these tutorial projects who address your specific sensor - there are plenty of them. And don’t panic: most of them cover the wiring, too.
Then, go and add a camera. Use a low-resolution device, it makes image recognition easier. Once again, use the internet to educate yourself. Main purpose of this exercise is to become familiar with a suitable framework (or library) and how to write code for your specific requirements.
Some weeks later, when you are confident to operate the PI and the sensors in a manner which fits with your project, return to this thread: Then, we will talk about the mechanics and how to control them. Your post will not stay unnoticed.
@Rackan-Mansour said in Assistance Needed for Wiring in a Prototype CNC Gantry System:
Could you also give me a brief idea of how all the items should be wired? the duet, the raspberry pi, the pi camera, the ultrasonic sensor, the screen for the pi, the pump.
Really now? You're asking for a complete circuit diagram? Are you serious?
Your initial post lists a couple of electronic devices and asks how to wire them - entirely all of them. Same with your latest post. In a near-duplicate post, you request advice on the programming aspects - to be precise: on all of them.
Honestly, that’s quite a big shot, so it might be helpful to give us an idea of what base knowledge on your part we can build upon. So far, your request is just a mix of dropping names of components and marketing speech. At least you obviously master the latter one
Sometimes we've found that not every step gets documented …
… or, as you've confirmed, "elsewhere". In general, Duet is well documented, but as it is not just the firmware but a whole ecosystem which has to cover mechanical, electrical and UI topics as well, it requires a lot of reading (and, sometimes, deep digging). Finally, we got this forum - glad I could give a hint
My question is whether there is any behind-the-scenes stuff that happens in the firmware that we'd break with this strategy.
The macros tfree#, tpre# and tpost# are embedded in a number of steps RRF takes in response to a T# GCode. The macro names have been chosen by intent: they describe their role (or ”position”) in the tool change sequence. It is documented here: "Multiple tools and Tool change macros"
My worry is that if the M98 command is the last statement in one of the tool change macros (tfreeN, for example), will the fw believe tfreeN is completed when the M98 is called, or when the M98 completes?
You are free to call macros from within other macros, and once a macro is done, it returns control to its caller. If the calling macro has no further commands to execute, it returns control to its caller - which, in case of tfree#, tpre# and tpost#, is the already mentioned tool change sequence.
Studying the tool change sequence carefully, you don’t have to guess what the firmware ”believes”, you then know under what conditions the tool change macros (and whatever macros you call from within) are invoked.
I don't have an explanation for the behaviour
How is that possible. Same cable (Phone Cable (4m) testing)
The CAN bus is known as robust and error-proof, even with poor cables and in harsh environments. Why on earth does this special setup want to prove us wrong? Well, let me remind you of how this all began:
Remember the famous yellow line linking V– of both PSUs together? Before being told to add that, 3 boards were supplied by one, 2 boards by the other PSU, delivering 24V each, but without any common point of reference…
Between the PSUs, the voltage levels were undefined, or, for a better understanding of what might have happened in this case, can be assumed to having been quite high.
With CAN cables added, the potentials start to interact, currents flow along complex paths (see the schematics above) to establish some sort of common GND. Neither CAN ”H” nor ”L” are directly linked with V+ or V–, but: both lines go across all boards.
In other words: given the undefined potentials between two groups of boards, the voltages were negotiated via the CAN circuits - every single IC (MCP2542) or discrete component along the lines can be affected.
The ”soft” appearance of the fault(s) can be plausibly explained with a ”low current, high voltage” event, similar to what happens intentionally in EEPROMs. Else, we could observe burnt resistors or visibly damaged ICs.
Further evidence of subtle effects of the kind I described above is given by the fact that the problem spreads across at least 2 boards and depends ”somehow” on cable lengths - as if the CAN circuity has developed some kind of ”antenna sensitivity”.
@developeralgo222 said in Duet 3HC Expansion looses Connection:
I love the Duet Boards, Duet Open Source Project and the options offered by them but i am not gaining any confidence in the reliability of boards. I might just be unlucky and got a bad batch, what are the chances of getting 2 x 6XD boards plus 2 x 3HC might not be working correctly out of 6 boards (2 x 6XD, 4 x 3HC ) ?
Instead of spreading doubts about the quality of the boards or the engineering capabilities, better use Ockham's Razor: a single cause of failure is more likely to happen than multiple problems across multiple boards at once.
@Rackan-Mansour
Could you explain more about the g code
Read: https://docs.duet3d.com/en/User_manual/Reference/Gcodes