Best posts made by SnowCrash

Hi,

I wanted to share the FSR controller module for auto bed-leveling that I've designed to work specifically (but not exclusively) with the Duet.

Background

The initial inspiration for this mini-project came from JohnSL's excellent open-source project for this application.

At first I thought I'd experiment with the ready-made kit that's based on John's work and sold online commercially, but given the price-tag ($34.95 before shipping), I decided I'd rather make my own module with the exact specifications I'm looking for.

Both John's module and my own are designed to run 3 x FSRs (Force Sensitive Resistors) simultaneously, like the one shown below:

I got mine at RapidOnline, but they are readily available from numerous other suppliers, either with long or short leads.

The PCB dimensions of John's module and the one I made are also similar (though mine is slightly bigger), but that's where the similarities end as both the hardware and firmware are fundamentally different.

Design Considerations

I wanted to create a module that:

• Can be seamlessly integrated with my Duet, but can also run in standalone mode (for testing and/or use in other, non-Duet machines).

• Runs as fast and reliably as possible.

• Has a minimal footprint.

• Offers a convenient and easily accessible user interface, including onboard LEDs for indicating the initialization process and real-time sensor triggering.

• Is able to automatically and quickly establish a baseline at startup against which to measure subsequent bed probes during the bed-leveling procedure.

• Incorporates an adjustment mechanism for controlling the sensors' sensitivity level.

• Can be reset manually to re-establish the measuring baseline.

• Can be turned on (for bed-probing) or off (after the procedure is done).

• Has an ICSP capability for bug fixes and/or future firmware updates.

• Facilitates expandability to 6 x FSRs in case I'd like to go down that route at some point.

PCB

After some reading, head-scratching, and playing around with the PCB editor, I came up with the following design that covers all of the above:

Hardware Specs

• 5V Supply Voltage (I considered going with 3.3V like the Duet's logic, but in the end decided against it because I wanted the microcontroller to run at max speed)

• Atmega328P-AU (smd version) @ 16MHz with an external crystal (for accurate timing)

• ICSP header (for firmware updates/bug fixes)

• Reset Button (for re-establishing the baseline for trigger measurements)

• 10K Trimmer (for manual sensitivity adjustment)

• 4 x LED indicators (1 x for power [green], and 3 x for each of the sensors [amber])

• Signal Output - an Active-Low Open-Collector Combined signal for the 3 sensors (the signal is 5V, but is nevertheless compatible with the Duet interface via an onboard reversed diode).

• An inductor/capacitor circuit for improved ADC readings of the sensors.

• Control Input - for turning the module on/off via one of the Duet's I/O pins (see the Schematics pdf attached below for an example of how to turn the module on/off with the Duet).

• Control Jumper - normally remains open, but can be closed to keep the module permanently on (for independent testing and/or use in other machines).

• Pull-up resistor Jumper - normally remains open (as the Duet already has built-in pull-up resistors on its signal input pins), but can be closed for independent testing and/or use in other machines (essentially, closing this jumper converts the signal from open-collector type to a regular 5V/GND signal, but note that the signal is still Active-Low, i.e. 5V means none of the sensors is triggered, and GND means one or more are triggered)

• Reversed Polarity Protection for the module's supply lines (by means of a P-channel mosfet).

• The PCB itself was designed with the free version of Eagle and manufactured by OSHPark.

Firmware Specs

• Firmware was written in Arduino-Style C using the free Arduino IDE.

• I've used the 'nano' bootloader - rather than the conventional bootloader for the Atmega328P - because the smd version of this chip has more I/O pins and thus requires an appropriate bootloader to run properly.

• When turned on, the module runs a quick calibration procedure (about 2 seconds), in which it samples each of the sensors and establishes a 'baseline' average against which to check sensor triggering at runtime (this is a crucial feature for preventing false readings from the sensors as there will always be some initial pressure present (from the build-plate's weight if nothing else).

• The initialization (or calibration) process is visually indicated by all amber sensor LEDs flashing 4 times, after which the module enters runtime mode.

• During runtime, the output signal is pulled low and the relevant amber LED lights up whenever one of the sensors is triggered (two or more sensors can be triggered simultaneously).

• If sensor triggering appears to be too sensitive or not sensitive enough, the 10K trimmer can be adjusted and then the reset button clicked so as to re-run the calibration process.

Open Source Design Files

Important Disclaimer: I've been working with electronics for a long time, but I am nevertheless a hobbyist and not a professional hardware engineer of any kind. I can therefore give no guaranty about the content of these files, apart from the mere fact that I've built the module and tested it myself. Hence, should you choose to use any of the following materials (or their derivatives), you must also be willing to take full responsibility for doing so.

fsr controller - schematics (pdf)

fsr controller - parts (Excel .xlsx)

fsr controller - firmware (Arduino .ino)

fsr controller - schematics (Eagle .sch)

fsr controller - schematics (Eagle .brd)

See It Live!

Here's a link to a short demonstration of the module in action

You'll notice that I click the 'reset' button on the module right at the beginning of the video - this is just to show the initial calibration process and isn't needed for normal operation.

Also, I haven't had a chance to install the module in my printer yet so there's still a lot of testing and potential firmware/hardware tweaking to be done, but given that many others have successfully implemented similar FSR architectures for bed-leveling (for example, see here), I'm hopeful this particular implementation would work out well too.

Should there be any interest, I'd be happy to report back on my progress with this, and of course, all comments/suggestions/corrections are always welcome

Thanks for reading,
SnowCrash

I wanted to add a postscript to this thread in praise of Duet3D's exceptional customer service.

Identifying the hardware problem with the controller has taken a bit of time and effort (thanks again Phaedrux & dc42!), but once this was accomplished - and notice that dc42 was responding to my queries over the weekend(!) - the matter was resolved extremely efficiently and quickly.

I sent the email to Duet3D with the replacement request on Saturday. I got a response first thing Monday morning to let me know that a new board is on the way, and the board itself arrived the very next day!

Customer service was a major factor in my decision to go with the DuetWifi. As we all know, everybody are great at the point of sale, but very few follow it up later on if/when problems arise. Prior to buying the DuetWifi, I've seen posts from other people commending Duet3D for their customer care, but now I can also vouch for it from my own personal experience. The process was extremely efficient and pain-free. I didn't need to chase anyone or sit and wait till someone got around to sorting it out.

Well done, Duet3D, and keep it up! you'll certainly gain many more loyal customers like myself!

I feel your pain, @biscuitlad, and hope you won't give up on your printer despite all the trails and tribulations you've experienced so far.

Like you, I've been having some mighty struggles with the g-code-based approach to config.g. It's undoubtably a steep learning curve for anyone not previously familiar with it.

As you rightly note, the Duet eco-system is very complex and offers multiple configuration possibilities, but to my mind at least, that's actually plus. The problem, of course, is finding the right configuration for the machine at hand...

I don't know if (or how much) you've tried to get help from other members in this forum, but in case you haven't, I'd certainly recommend trying that.

On the other hand, if online requests for assistance didn't produce the desired results, perhaps it might be possible to find an experienced Duet user somewhere in your vicinity who might be willing to drop by and get you going on the right track? There are lots of good people on this forum and I'm sure they'd be happy to help if they can.

One other point I'd make - and I don't know if you'll agree with me on this, but it seems relevant - is that in my view, your case provides yet another example of the need to significantly upgrade the documentation so as to bring it on par with the high level of the Duet's hardware & software. Personally, I think the documentation is lagging way behind atm.

Don't lose hope, @biscuitlad! Sometimes it's good to just take a step back and let things rest for a while before having another go

@t3p3tony said in DuetWifi & PanelDue 10-Pin Ribbon Cable Hookup Clarification:

@t3p3tony and now its fixed:

I'm not sure this is the correct place to post this comment, but it's related to previous posts so here goes.

Having done a lot of work in the past couple of weeks with this excellent pinout diagram, it occurred to me to suggest a tweak that I know would be very helpful to me and hopefully to others as well.

The connectors on the board are of course keyed, however, the diagram doesn't reflect the keying direction. This means that when making a new cable for one of the connectors, I first refer to the diagram for the order of wires and then need to look at the actual board to check in which direction the connector is keyed.

On the other hand, had the diagram also included the keying direction of each connector, it would make things much simpler as there wouldn't be a need to check the actual board when making new cables.

Hi @phaedrux, yes, very much so Thanks!

@dc42 said in Detect overheated driver:

Unless you are using very old firmware, you will get warning messages in the Console pages of DWC and PanelDue if the drivers overheat. You can also use M305 to set up a virtual heater to monitor them.

@dc42, could you please give a couple of concrete examples of how to set up a virtual heaters for, say, Driver 0 (X-Motor) and Driver 1 (Y-Motor) using the M305 command so that they could be monitored in DWC?

I've read and re-read the documentation on this here, but still not sure what the specific parameters ought to be, mainly the 'P' parameter.

What I find a bit confusing is that in my config.g I have:

M305 P1 T100000 B3950 C0 R4700 ; Set thermistor + ADC parameters for heater 1;

But, unless I'm mistaken, that would mean P1 is mapped to the E0 driver which runs my extruder stepper, so I'm not sure how the axis drivers are mapped to the 'P' parameter.

I'm also not entirely clear what other parameters are needed in this context (if any)?

Edit: I hope this isn't highjacking your thread, @mperdue . My question seemed directly relevant to your query, but if needed, I'll happily start a new one).

Hi,

I understand the frequency of the PWM fans can be changed via the F parameter of the M106 command.

I've seen a comment by @dc42 here suggesting this frequency be set to 25KHz, however, I'd like to know what's the maximum frequency the hardware & firmware allow the user to set?

Btw, this seems like a good place to offer my 2-cents on this subject. Although I'm a newbie to the DuetWifi, I've been working with PWM fans and pumps for a long time and there are two things I find baffling about the DuetWifi's setup in this context:

(1) The default frequency for the PWM fan outputs seems to be 500Hz. That may suitable for LEDs, but certainly doesn't even come close to what PWM fans typically need to to work efficiently (and quietly!).

Although there isn't an agreed industry standard on the suitable frequency for PWM fans, many applications use a 25KHz signal, while the recommended frequency in many of the more reputable sources I came across over the years set the value even higher at 31.5KHz. My experience has been that the latter works very well in most cases.

On the other hand, a 500Hz frequency will almost invariably drive PWM fans very poorly as indicated by a particularly annoying whining sound most of them would generate at this frequency.

I therefore think it would be a very good idea to change the default frequency value to something along these lines so that people who aren't aware of this setting would still be operating their PWM fans at a reasonable frequency.

(2) The DuetWifi has only 2 pins per fan connector, hence no dedicated PWM line. Consequently, I'm assuming the so-called 'PWM control' of the fans via the DuetWifi is achieved by pulsating their input voltage.

If this is indeed the case, this isn't a great idea. Non-PWM fans aren't designed for this method of operation and operate much better (and quieter) when their speed is varied through voltage control.

Don't get me wrong, I think PWM is phenomenal and I certainly use it wherever possible. Also, there are ways to implement voltage variation on the basis of a PWM signal, but unless I'm completely off, this isn't how it's implemented in the DuetWifi.

Hi,

The gcode wiki specifies a 'Dive Height' parameter (Hnnn), but I couldn't find an explanation about what this parameter does or how it works.

Could anyone please clarify?

Many thanks,
SnowCrash

@phaedrux said in Detect overheated driver:

I believe I recall @dc42 saying previously that the drivers are monitored for a high temp and overtemp, hence the two virtual heaters. The reason for being combined being that they are intended to be used for thermostatic control of a case fan. The hottest driver would trigger the increase in cooling.

Since the drivers can generally be run passively cooled I don't know the benefit of knowing exactly how hot they are since we can already achieve a cooling strategy with virtual heaters provided.

As Deckingman said, adding a thermistor would get you the exact temp and associated control.

Ahh, now the 2 virtual drivers vs 5 physical drivers make more sense - thanks, @Phaedrux! Shame it's not in the wiki...

Also, as always, you make great points here.

Nevertheless, I can see at least one advantage to being able to monitor the actual temps (or even just the status, i.e. high-temp and over-temp), which is it provides a way to verify that the temp-control fans are indeed operating as intended. Put a different way, atm how do you know that the fan comes on when it needs to?

@dc42 said in Grounding!:

And yes, stepper motor cases should be grounded, to prevent the buildup of static charge caused by the moving belts.

I have the printer's metal frame grounded to the mains ground (AC ground), but I was wondering in the context of the above discussion:

Would it be preferable to ground the motor cases to the negative DC terminal of power supply's (DC ground) or the main's ground (AC ground)? or, perhaps , no difference?

@deckingman said in Help Configuring PWM Fan in Thermostatic Mode for Duet Drivers:

@dc42 said in Help Configuring PWM Fan in Thermostatic Mode for Duet Drivers:

@joergs5 said in Help Configuring PWM Fan in Thermostatic Mode for Duet Drivers:

If the TMC chip does not report temperatures correctly, isn't it better to measure the temperatures with a sensor yourself (e.g. at the heat sink of the controller which is under max load, so X or Y controller) and take this temperature to decide how to handle fan speed?

If the drivers get hot, they will heat the CPU through the PCB. So you could use a combination of the CPU temperature and the driver warning to handle fan speed.

For info, using a thermistor stuck to a driver chip controlling a fan to blow air onto the back of the boards, after an hour or more of printing, I typically see the driver temperature reporting about 15 degrees higher than the CPU temperature. More specifically, with the fan running in thermostatic mode between 40 and 50 deg C, I might see 47 degrees on the driver but only 32 being reported for the CPU. I did calibrate the cpu temperature by using M912 so they both read the same at an ambient of about 22 deg C.

Awesome, @deckingman, thanks!

In that case, I might switch to monitoring the cpu temp instead of the drivers as it would give me the gradual fan speed ramp up I'm looking for.

How do you monitor that particular temp? (virtual heater number?)

And could you please tell me how you calibrated the cpu temp?

@deckingman said in Detect overheated driver:

@phaedrux said in Detect overheated driver:

@snowcrash It may be in the release notes from back when the virtual temps were introduced. But yes, it would belong in the wiki.....................

You can find it in the Wiki here https://duet3d.dozuki.com/Wiki/GCode#Section_M305_Set_temperature_sensor_parameters

Unfortunately, I'm afraid I can't...

To the best of my understanding, this is what the wiki has on virtual heaters:

Pnnn Heater number (0, 1, 2...) or virtual heater number (100, 101, 102...)

Channel 1000 is the on-chip microcontroller temperature sensor
Channel 1001 represents the temperature warning and overheat flags on the TMC2660 drivers on the Duet Wif/Ethernet. It reads 0C when there is no warning, 100C if any driver reports over-temperature warning , and 150C if any driver reports over temperature shutdown.

Channel 1002 is as channel 1001 but for drivers on the DueX2 or DueX5.

Virtual heaters 100, 101 and 102 are preconfigured to use temperature sensor channels 1000, 1001 and 1002 respectively. We suggest you use virtual heaters 102 upwards if you want to create additional virtual heaters.

I don't know about other members, but I find this description not only confusing, but lacking in the most important respect, namely: how to set up and use existing/new virtual channels in practice.

To take just 3 examples:

As @Phaedrux's comments' revealed, the functions of virtual channels 101 and 102 (high-temp and over-temp) for the drivers aren't mentioned in the wiki at all (they are only mentioned in relation to the CPU 100 channel.

I assume there's a mistake in at the end where it says '102 upward', as it seems channel 102 is reserved for flagging 'over-heating' of the drivers, no? shouldn't it be '103 upwards'?

Moreover, what are 'temperature sensor channels 1000, 1001 and 1002' mentioned above? where do I find them? are there additional temperature channels I can use/create? how do I utilize them? and, in case I'd like to use create new virtual channels, how to I configure them to work with other those 'other channels'?

Of course, I don't expect you (or anyone else) to write a whole tutorial on how to use virtual channels on the Duet within the confines of this modest thread.

On the other hand, from my perspective as a newbie to the Duet eco-system, the info in the wiki on this subject isn't really comprehensible nor detailed enough to be actually useful.

Hi @jckray,

Glad you got it sorted out.

Just thought I'd chip in about the issue of PWM frequencies for the benefit of anyone else struggling with pulsating fans and potentially reading this thread. 100Hz (or even 1000Hz for that matter) is way too low for PWM fan signals. Although there's no one frequency that's suitable for all PWM fans, conventional wisdom puts the number at 25,000Hz (or 25MHz), while some even opting for a little higher (around 30MHz). Often times, changing the frequency to that level makes a significant difference in terms of the fan's acoustics.

I picked up the 10-pin Molex Micro-fit 3.0 male and female connectors for this purpose and so far I've been very happy with that choice.

• They are relatively small, but not too small so as to be fiddly or fragile

• They have very good 8.5A(!) power rating (for the hotend power lines), according to this source

• Crimping the wires with a long-nosed plier is easy enough (I don't have a crimper...)

• They are 'keyed' so orientation can't go wrong, and they have a quick-release latch to boot.

• Good overall quality (made by Molex)

If you're interested, part numbers are:

Male Plug: Molex 43025-1000

Female Receptacle: Molex 43020-1001

Male Crimps (for male plug): Molex 43031-0001

Female Crimps (for female receptacle): Molex 43030-0001

Btw, just did a quick check and if you need more pins they have these connectors with up to 24, which is essentially the main connector on motherboards or very similar to it (molex part number: 0430252400).

Hi,

This subject always get my brain in a twist so I thought I'd ask for some help

My steppers are 0.9 degrees (400 steps per revolution).

I currently have these high-helix lead-screws from Igus installed: DST-LS-10x25-R-ES, which have the following specs:

Diameter: 10mm
Pitch: 25mm
No. of threads: 8

With micro-stepping set to 256 (x16 with interpolation), this comes down to 256 steps per mm (I know it's right cause it works in reality, but I completely forgot how I got to this value).

Now I'm considering going with similar lead-screws but with shorter pitch (yet also less threads), in the hope of increasing the resolution.

The intended lead-screws are also from Igus: DST-LS-10x12-R-ES, and they have the following specs:

Diameter: 10mm
Pitch: 12mm
No. of threads: 4

Could someone please help me calculate how many steps per mm would this lead-screw yield? and, for my education, how the calculation is done?

Btw, I'd like to keep the 10mm diameter as my lead-screw nuts and the bearings are all for that size and I'd rather change only the lead screws themselves if I can.

Many thanks in advance,
SnowCrash

@red-sand-robot said in Print cooling fan not working properly:

@snowcrash Not sure if I am understanding exactly how PWM affects the fans, but could setting a high frequency (as in the mHz range as you mentioned) damage the fans or the board at all?

I'm running a 24v blower fan and any time I set it lower than 100% it emits a high pitched whine (at 500hz). Curious as to if changing the frequency to much higher will remove the whine without damaging anything

Raising the PWM frequency to the levels I mentioned won't cause any damage to the fan or board (btw, I previously verified with @dc42 in another thread that the board can generate these frequencies and indeed it can). I'm not surprised your blower whines at 500Hz. Give 25MHz a go and see if it solves the problem (don't forget the value is entered in Herz, so 25000).

@samlogan87 said in Print cooling fan not working properly:

@SnowCrash so 25kHz is what you recommend for even a 2 wire fan that is pwm’d? The wife got sick of the whine so I ordered some 4 wire fans but in the mean time should I bump it up that high as it might be a few weeks before the others show up.

Regards,
Sam

Hi Sam,

No reason not to try and see. Though certainly not all 2-wire fans like to be PWM'd as they weren't designed for this kind of operation, still in many instances there will be a significant improvement with higher frequency in terms of noise (and functioning).

Btw, if you're hooking up a PWM fan to the Duet by running the blue (=pwm signal) wire to the GND pin of the fan header and independent power lines to the fan, don't forget to add the protection diode on the signal line.

For anyone interested, I dug up 2 previous discussions on this topic in which @dc42 took part (and also include instructions on the said protection diode):

https://forum.duet3d.com/topic/6054/help-configuring-pwm-fan-in-thermostatic-mode-for-duet-drivers/4

https://forum.duet3d.com/topic/5248/maximum-frequency-of-pwm-fans

@wilriker happy you got your fan working quietly (though perhaps not in the way you were hoping to achieve this )

Anyway, at another discussion, @dc42 insisted that an inductor-capacitor circuit is necessary for preventing a non-PWM fan from potentially being damaged while being run with a high frequency PWM signal, and just I started looking into the idea of making a little add-on module that would provide this circuitry for all 3 PWM outputs on the Duet (plus the ability to choose between 12V and 24V for each fan which is the main reason for the module).

So hopefully @dc42 or someone else familiar with this subject would chime in and clarify this point about the inductor's value.