@TobiAsis said in Driver Error and MCU overheating:
Do I understand correctly that essentially these areas are the heat dissipation zones?
Heat dissipation occurs over a much larger area, but the marked spots are of central importance for this to work: The holes are copper-coated and transport the heat vertically through the multilayer circuit board.
@TobiAsis Did you study the Mini 5+ Hardware Overview?
In the section Cooling it states:
In many applications passive cooling will be sufficient, especially if the board is mounted vertically in a well ventilated position. If active cooling is needed then a fan blowing across the back of the board along the line of the stepper drivers is recommended.
The stepper drivers' heatsinks are connected to the PCB and the majority of the heat is dissipated via the PCB so heatsinks on the stepper driver chips are largely ineffective.
Looking at your photo, I doubt that much heat can be dissipated from the PCB’s back. Better ventilation or active cooling may be required.
To the temperature readings you get: The two subsequent paragraphs in the above mentioned doc (”MCU Temp” and ”Stepper Driver Temp”) explain why RRF reports strange values.
what I need is that for every single movement made by any of the motors being controlled, a logical "1" signal is generated exactly when that movement has finished, and then it must return to "0".
Without context, i.e. without relating the event to a specific command, your data acquisition is no more than a platonic exercise. Maybe your goal is to develop and test this ”data acquisition board“, but to obtain meaningful data, you should simply control the Duet by setting up a HTTP client https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests#get-rr_gcode. By this, you could even observe RRF’s object model.
Does someone know how to proceed or which file do I have to modify?
RRF is Open Source, so feel free to study the code at GitHub. But beware: RRF is a very sophisticated piece of art, so you should have more than just some basic knowledge of C/C++.
@elmoret Sorry, no time to blog as long as I make 
I started my 3D printing ”career” 7 years ago with an RFID controlled time recording terminal - a USB / HID device attached to some iMacs in a medium-sized factory. Bought the casings, but needed mounts for display, Arduino and other components within. So I bought a CR10 bed slinger, instantly replaced the controller with a Duet, subsequently re-printed most of my printer, modding it heavily (water-cooled Chimera, heated chamber, etc.).
As I just print mechanical parts, often for outdoor use, I almost exclusively use PETG. For my electronics, I mostly rely on Arduinos of some kind, often using several of those communicating over CAN. Here are some random projects of mine, all using 3D printed parts:
Hydraulic work platform / scaffold - conversion to electronic / remote operation:
Wheel loader - conversion to electric drive:
Lawn tractor / mower:
Kneading machine:
”Mobile socket” / outdoor power station:
Gas burner:
Thermostats:
Bikes:
27" iMac to Thunderbolt display conversion:
@zuoyan With a 3D printer or CNC router, you typically need multiple harnesses - in some few of them you might be able to combine voltages or GND. Connectors, plugs and sockets must then be carefully chosen to allow for high currents. All signal lines and connections to sensors, end stops and the like should be kept separate, sometimes they even need shielding - don’t trick with these. @jay_s_uk is right when he suggests to use CAN-FD toolboards: this is by far the most effective solution to avoid wiring nightmares.
@HugoZM From your posts, I imagine you run a 6HC with a PanelDue attached, no boards on the CAN bus, and you control your printer from a PC running DWC (Duet Web Control) in a browser. The PC is connected via ethernet, not over USB. Please correct me if I’m wrong, I can’t see your setup from over here.
Something went wrong with the M122 report - it should begin with something like this:
code_text
``
=== Diagnostics ===
After the ethernet connection is lost, you can’t call M122 from DWC any longer - in this case, restart the Duet and invoke M122 immediately afterwards. By this, you can copy the report from the console. Yesterday, you were able to post such a report on @Phaedrux’ request.
Looking at yesterday's report, you are on RepRapFirmware version 3.5.1 - did you follow @Phaedrux’ advice to update the firmware to 3.5.4? And: which version is your DWC? (You can find this in the Settings / General tab of DWC).
To locate the LEDs on the 6HC, this Wiring Diagram is helpful. Most LEDs are located near the bottom left of the diagram. Within the 6HC’s Hardware Overview, the LED’s meanings are listed here.
Check the voltages (V_FUSED, 12V+, 5V+, 3.3V+, USB) and the STATUS LED after boot, then look if something has changed after the loss of ethernet.
If the LEDs give no hints, try the following:
Please post your findings …
when I home the axis the ethernet stops working
Interesting. Welcome back 
I can’t imagine any firmware reason. I assume it’s either a mechanical or electrical failure. First, we need a lot more details:
Please send M122 after the event and post the report here.
So I should delete the M301?
comment these lines out and see whether you get a temperature rise.
Edit: And remove the M501 command at the very end of the config.
@HugoZM Sorry, but you posted the heater portion from your config.g file, NOT the file config_override.g which should contain, among other settings, the results of your PID autotune. This file (config_override.g) is called at the end of config.g with M501.
As I interpret your config, the M301 commands per heater kinda "reset" the tuning, setting all PID parameters to 0. See the GCode Dictionary for details. IMHO, this requires the presence of a config_override.g file.
As a side note: I prefer to place (copy/paste) the tuning results into config.g, the necessity of a second "hidden" parameter file obscures the real configuration somehow. But that's a matter of taste.
Thanks for your tool change files (tool 0). tpre0.g and tfree0.g are empty, tpost0.g just waits until the temperature of tool 0 is reached. If the same scheme applies to tool 3, that's where it waits forever and a second when you select T3 from the PanelDue - given that, for some reason, your tuning parameters have no effect.
@HugoZM Can you please post your config_override.g so that we can see which PID parameters are applied to the heaters?
When @jay_s_uk asked for your tool change files, you stated that you "don't have anything on them". Does that mean there are no tfreeN.g, tpreN.g or tpostN.g files in your /sys/ directory (N being the respective tool number) at all?
the issue is with daemon.g
in particular with calling macros which change led colour
@T3P3Tony already told you how to avoid the time to permanently reopen the daemon.g file. The same is true for calling the colour-change macros. As these are simple one-liners, you might want to incorporate these M150 calls into daemon.g directly.
@cdoe Do you use a daemon.g file? If so, what’s its content?
i purchased clones many times rather than originals, what business model is this?
Yours? The ”buy cheap” model. It relies on exploiting other people’s work. Would you buy ”the real thing”, you’d contribute to the costs of engineering and development for both hard- and software. On top, all users of genuine DUET hardware help keep this forum running. Not to mention in-depth documentation and technical support.
When approached for original boards still its 3 times higher than clones.
Yeah! So you profit from Duet3D’s work but honour the cloners. Were all Users like you, Duet3D (and all your beloved clones) wouldn’t exist.
@drivetrainsystems See this thread - reading-sensor-pressure-from-analog-output for details. You can skip the posts involving the "Bi-directional Level Shifter" which returns a digital signal.
i am not using U & V as @dc42 mentioned above.
That’s good, @dc42’s post was short but precise.
i will test it but would this work as my start of testing
M308 S1 P"2.io0.in" Y"linear-analog" A"VG1" F0 B22 C-123 V0.0 U0.0
Yes, that’s a good starting point. Don’t stick with the idea to define the minimum and/or maximum of absolute values in Bnnn / Cnnn. Instead, adjust these until the result reads 0 for 0 kPa and -101 for 101 kPa. So, if at 0 kPa, you get a value >0, lower B - or, if you read <0, enlarge B. Then, adjust C in the same way. However, you will notice that if you change C, the reading for 0 kPa will also change a bit. So, it's an iterative process with a lot of try and error.
Managed to mount 12 resistors ( that i had in hand creating 6 Voltage Dividers ( 1.8K & 3.3K ) per connection
The nominal values of the two resistors are fine. Depending on the resistor’s specs, the effective values may come with enormous tolerances of up to 20%, so in order to get identical readings on all six channels, you should use resistors with a tolerance of 1% (”E96”) or better (”E192”). Alternatively, you can hand-pick resistors with the help of a multimeter.
Now my issue is how to Calibrate it correctly .
Which M308 command do you apply? Is it still this one from your OP:
M308 S1 P"2.io0.in" Y"linear-analog" A"VG1" F0 B0.0 C-101 V0.00 U13.5
If I understand the ”Analogue Section” from the data sheet you provided in the OP correctly, the output voltage at 0.0 kPa is somewhere between 0.6 and 1V (but not 0V). The resulting range should span about 0.5 to 3.2 V. Assuming that you want the Duet to report negative values, the Bnnn parameter (”The temperature or other value when the ADC output is zero”) should be positive (with U at 13.5, try 22), not 0.0. Similarly, Cnnn (”The temperature or other value when the ADC output is full scale”) should be a bit larger, as the output will rarely reach 3.3V.
Think of Bnnn / Cnnn as defining an absolute scale (for 0.0 - 3.3 V), the effective readings being a subset (0.5 - 3.2 V) of that range.
i can't seem to get a good voltage divider to purchase that can handle 6 outlets.
I’m not aware of a commercial product either. Just mount 12 resistors on a perfboard - that’s it.
i need high accuracy and robust reliability , that's why i used a Voltage Level Shifter
The level shifter you want to use is inappropriate for the task: as @gloomyandy says, the TXS0108E translates logical (i.e. ”binary”) signals from one voltage level to another one. Please study the data sheet to understand what this device is intended to do. On page 17, they say explicitly what they do to your analog signal:
When transmitting data from A-ports to B-ports, during a rising edge the one-shot circuit (OS3) turns on the PMOS transistor (P2) for a short-duration which reduces the low-to-high transition time. Similarly, during a falling edge, when transmitting data from A to B, the one-shot circuit (OS4) turns on the N-channel MOSFET transistor (N2) for a short-duration which speeds up the high-to-low transition.
So, they don’t shift an analog voltage to another level, instead, they try to detect flanks and sharpen these for better digital signal quality. For your use case, that’s the opposite of ”high accuracy”.
A simple voltage divider is what you need. Using high-quality resistors, these are very accurate and highly reliable. I really have no clue why you disqualify them as ”simple but not robust”. The contrary is true. Towards @gloomyandy, you mention three alternative solutions: ”Zener Diode Clamp” and ”Opto-isolator”. Both are counter-productive: With a Z-diode, you can clip (or limit) a voltage, an opto-isolator is highly non-linear. Your preferred solution, a ”Bi-directional Logic Level Shifter”, falls in the same category.
If you don’t like voltage dividers at all, there is an alternative: Op-Amps. But designing a circuit with several discrete components is a major task and not worth the effort: any added accuracy is easily ruined by the subsequent A/D conversion on the Duet controller or by temperature shifts along all components in the signal path.