Posts made by Gixxerfast

@heide Hi, if you're using the hall effect sensor in its default location, may I ask why you define your X and Y endstops to be low end?

Normally on a Voron, the X0 and Y0 is front left corner of the bed. And you home at max X and Y.

Here's my endstop configuration:

; Endstops
M574 X2 S1 P"121.io0.in"                       ; configure active-high endstop for high end on X via pin 121.io0.in
M574 Y2 S1 P"0.io1.in"                         ; configure active-high endstop for high end on Y via pin io1.in

However, I do not use the hall effect, but that's just an inverse away.

Also, a simple M119 will tell you all you need to know, one where they should be activated and one where they should not be.

@asimitabi
Also make sure to have a look in here (or newer docs preferably)

// https://duet3d.dozuki.com/Wiki/Duet_3_Mini_5plus_Hardware_overview#Section_IO_port_pin_capabilities

https://docs.duet3d.com/Duet3D_hardware/Duet_3_family/Duet_3_Mini_5+_Hardware_Overview

I guess you want the pwm capability.

@asimitabi To me it looks like you have it connected to io4.

Or am I looking at the wrong picture ?

@kleslietx It's not unheard of that people have managed to use the wrong size pulley in the Z gearbox. Worth a check maybe.

@tim-c Without knowing for sure since I do not not own such a printer, a little bit of googling suggests that these are 12-24V NPN inductive sensors which means that they require at least 12V to work reliably.

Have a look in this old thread: https://forum.duet3d.com/topic/12056/npn-12v-endstops-at-duet-wifi

If this is correct, it will behave as my old PL-08N2 inductive probe and output near input voltage when near a metal object. Just make sure that your input port can handle the higher (>3.3V signal) voltage.

@e4d May I ask which SSR you are using as many, for example, Omrons are speced to at least 5V to switch.

Example:

Apologizes to those who contacted me about the board, I have been (and still am) a wee bit under the weather but I'll respond to you shortly.

Anyway, I thought that a good test for the board would be to hook it up to drive the A & B motors on the Voron V0.1 running two Nema 14 motors at 1200 mA at 4000 mm/s^2 (5000 travel) and see what happens.

Said and done. Start:
https://youtu.be/Jh0_QzTjQ-Q

End:
https://youtu.be/QYoGkQ9I5lc

Finished test print:

With this I'm pretty sure it will ahev no problems winding some filaments up and down with th ERCF

Btw, the enraged rabbit feeder is on the way

I have another new version in mind that utilizes more Duet hardware but it requires more changes to the firmware changing the slave addressing. Shouldn't be more that a few places. Maybe a couple of ifdefs is enough

I just love the Duet hardware and RRF. Swap two drive cables. change two lines in the config.g and restart and you have swapped motor drivers to another board.

@r4ffers Well, I have some extra boards to sell. The tricky part is to get hold of a Sammy. the ATSAMC21 is a bit unobtanium at the moment (for us regular folks anyway)

So, the latest beta version of the Canned ERCF expansion board is back from JLCPCB and is ready. It seems to work fine though I'm in the middle of building the actual ERCF

It will require some more testing to be sure that there are no major flaws left.

Canned ERCF board

The main differences to the first version is:

• Added a 4.7Kohms pullup resistor on the TX/RX UART line to keep the line high when Duet firmware momentarily disables UART when reading and transmitting. This can be handled with software changes but that will make maintenance harder as there will be more code to keep up to date.
• Added a 480 ohms series resistor on the io0.out PWM pin (to the servo)
• Added over voltage protection (up to 30V) to the io1.in, io2.in and io3.in inputs
• Added VIN voltage monitoring.
• Added separate CAN connectors to make it easier to hook it in the middle between the board and for example a toolboard.

I have made a fork of the Duet3Expansion firmware here which with the changes above only required changes to the SammyC21.h configuration file.

There is some history regarding this board in this thread.

@phaedrux It's from here as far as I can see: https://duet3d.dozuki.com/Wiki/M106

But can you really refer to it via number >=100 in the H parameter ?

I see nothing that implies that.

OK, so with RRF V3 you cannot use +100 to refer to the MCU or other sensor (virtual heater) as I initally wrote far above here somewhere.

@fcwilt Yes, that sound reasonable which made me try it as I set it up explicitly.

I changed my config to:

M106 P2 H100 L0.2 X1.0 T30:50 C"Controller fan 1"

When I run that config I get:

Error: Sensor number out of range

Also, when I look in the code I see nothing that suggests that there exists predefined sensor numbers

The sensor number list that s set via the H flag is checked with this:

if (hnum < (int)MaxSensors)
					{
						sensorsMonitored.SetBit((unsigned int)hnum);
					}
					else
					{
						reply.copy("Sensor number out of range");
						error = true;
					}

And as far as I can see the MaxSensors is between 32 or 56 depending on board. I am very likely reading something wrong here as it's not very quickly easy to see what MaxSensors is defined to in this case.

@fcwilt Edit: No it isn't Is H100 predefined as MCU temp?

@cozyp Can you run m98 P"/sys/config.g" and post whatever shows in the console?

As far as I can see right now, the last M106 is still referencing a heater that prpbably doesn't exists. H100 ?

So just to make it clear:

• Fan 0 is part cooling fan, which is controlled by slicer GCode commands
• Fan 1 is the extruder fan which is controlled by the temp of heater 1 and should turn on whenever thet temp is over 45
• Fan 2 is the controller fan which is controlled by sensor MCU temp that you have probably defined that somewhere?

Here's mine:

; Define MCU sensors which will be available in DWC Extra View
M308 S3 A"MCU" Y"mcu-temp" 				; Officially NOT supported on Mini 3 5+ however seem to work
M308 S4 A"Duet Drivers" Y"drivers" 		; This is not really working as it is just a threshold crossing

And I'm referring to those with:

; ==================================
; MCU fan
; ==================================
M950 F2 C"!0.out4+0.out4.tach" Q25000              ; create fan 2 on pin out4 and set its frequency
M106 P2 H3:4 L0.2 X1.0 T30:50 C"Controller fan 1"  ; controlled by Sensor 3&4 - MCU& Drivers

@barracuda72
Connect it NC gnd to pin and you shouldn't have to change anything

As I wrote elsewhere, I think his problem is that he has a NO switch connected to 3.3V so when not pressed down it leaves the pin "floating" which is then pulled high. So it's already at 3.3V when the button is pressed so no signal change can be detected.

I feels like a reasonable explanation AFAIK.

The solution could then be to change to switch ground to the io pin and use the S0 parameter instead, not that I've tried it.

@phaedrux @jcwild A question/observation. Do you know how these clones work in regard to logic levels? I see that the Z_PROBE_MOD pin is, as far as I can see, a 3.3V logic level pin and I haven't been able to find any information that the 3DTouch is working with 3.3V

Isn't a logic high often relative to the input voltage, (therefore sometimes Neopixels work with 3.3V if the input voltage is low enough)?

I see that the same output is buffered to 5V to the servo pin. Is that an option to see if it could work (more reliably.)

@cozyp said in FAN 0 & FAN 1 allways ON:

; Fans
M950 F0 C"fan0" Q500 ; create fan 0 on pin fan0 and set its frequency
M106 P1 S1 H1 T50 ; set fan 0 value. Thermostatic control is turned on
M950 F1 C"fan1" Q500 ; create fan 1 on pin fan1 and set its frequency
M106 P1 S0 H102 T45 ; set fan 1 value. Thermostatic control is turned on
; Tools
M563 P0 D0 H1 F0 ; define tool 0

May I ask what you're doing here (above)?

Fan 0 is usually/often the part cooling fan which should be controlled by the slicer Gcode and as set in the tool def M563
Maybe you should define it something like this? :

M950 F0 C"fan0"                              ; create fan 0 on pin 121.out1 and set its frequency
M106 P0 S0 H-1                                   ; set fan 0 value. Thermostatic control is turned off

The second part/fan is monitoring heater 102 (if I read this correctly) Which heater do you want to monitor? I guess H1 is what you want.

@benecito I would check with a m122.

If the PSU is bad and supplying under 10V (IIRC) the drivers will not be enabled.

Wow, spectacular. Not the sort of thing I'd want to happen to my printer.

Please take this the right way as not trying to cast any shadow on the description here at all only trying to understand would could cause such a major breakdown..

But I would like to ask if you perhaps had heat sinks attached on the driver chips? I see that you have one on the MCU and that usually runs much cooler than the drivers in my experience.

@tryingtomakestuff OK, because they should be crossed:

Anyhow, I'll leave it there