The sensor itself is a resistor? So soldering without touching each other?
Solder joints iin the immediate vicinity of a hotend which can easily reach the temperature of a soldering iron? Perhaps not the best idea. Better replace the temp sensor with a new one. There’s a reason why these come with heat resistant connection cables.
@SimonM Overall, the details you provide hint at an industrial application. If so, you will run into problems, mainly these ones:
• Concurrency. In this realm, Duet/RRF has rather sophisticated capabilities, but they can not really be controlled by the scripting language. In a simplified model, RRF maintains an execution queue (in fact, there are two) of certain commands. Some commands are executed out-of-order, and before you run a ”subroutine” (e.g. another script file), the queue must dry up. You have to take care that each new script waits for completion of the current one - which can slow down operations if each of the numerous triggers (optical or mechanical switches) invokes a lengthy script file on its own. Usually, you’ll need some kind of state machine to sync execution - with a scripted language, that’s a major task.
• Forget about storing the state of storage positions on the SD card. As each ”AS” and ”AR“ op would require at least one write access, the SD would wear out rapidly. As I’m familiar with the ways to store and retrieve data to and from files on the Duet, I can safely state that there is no simple way to evaluate a bunch of stored numbers on the fly. For instance, it is near to impossible to operate ”real-time“ on tables like the height map by a script. You can hold and maintain a limited amount of data in RAM, but these have to be inited every time on power-up, so plan for that.
• The PanelDue is not suited for use as a general-purpose UI, you would have to customise its firmware. DWC might be an option if you use a plug-in like BtnCmd, but I doubt it will fulfil the requirements for industrial use. Possibly, you can’t help but to couple the Duet with a RasPi and write some dedicated stuff for Linux. This way, you have a good instance where to implement a state machine (with permanent storage) as well.
I can provide the following meat
Thank you for providing so much detail. That’s truly much meat for further discussions. So let’s start.
• The Duet controllers are great in that they provide an elaborate motion system, they should cover all aspects of picking up, moving and deposit the objects in 3-dimensional space. They also provide a lot of I/O, so that you can deal with analog and digital inputs - who then can trigger events (invoke sub-programs), which is useful to control actuators etc.
• Typically, RRF is controlled by a stream of commands, i.e. GCodes. They tell the Duet where to move or what other action to execute. IOW, RRF/Duet has no idea of the items to move or of the storage locations, you need an external instance which translates the idea of a storage system into GCodes. In 3D printing, that’s the slicer, for PnP machines, OpenPNP does the job.
• For ASRS, you have to develop your own system, which is quite easy in case of a FILO (first in, last out) or FIFO (first in, first out) type of serial storage. These trivial cases can be scripted and run on a Duet. If you need to store different types of cable assemblies in specific storage compartments and to retrieve them according to type or some other scheme, there’s no way but to use a RasPi or similar system.
• It may be difficult to maintain the state of the system (storage capacity of several slots) over time. After every reset, the Duet has to re-calibrate itself, count all items per storage location and init several counters. How many storage queues are we talking of?
• Some sensors involving image- or pattern recognition need an external controller (these belong to the subsystems I mentioned in my first post). An external controller (such as an Arduino) may also be required if you have to interface lots of simple sensors (mechanical or optical switches).
• Do you have a concept of necessary controls - buttons and the like? Except of the automatic pick-up, how will humans interact with the system? All this affects the required I/O capacities.
• You mention imperfect spacing and inaccurate positioning, I would add potential jams and other malfunctions. Depending on the required level of perfection, the subsystems (pick-up, storage queues, goods issue) can become deliberately complex. After specifying some numbers (queues, items/queue, approx. dimensions, timings), the subsystems must be defined in order to guess how many sensors of which kind are needed. With all these details, you can make an educated guess whether RRF/Duet can do the job, of whether it needs to be assisted by an external RasPi.
Although automatic storage and retrieval systems (ASRS) are common industrial items, it seems there are relatively few diy attempts published to any great level of completion, beyond basic proofs of concept (please share links if I'm wrong on this).
You are wrong on this. There are many PNP solutions out there, use the search feature to find many posts on this forum for RRF powered automats (don't thank me for the hint…).
I envisage that the effector may need an RC servo …
I envisage a small set of loading points …
I imagine an optical or inductive sensor…
Many envisages and imaginations, no real meat. Are you maybe tasked with a seminar paper or some similar exercise? Just to clarify: this is a forum for makers, not ghostwriters.
Take my good advice: Sit down and conceptualise all necessary building blocks - mechanics, sensors, actuators, controls, interface(s). Sure you can use a Duet to control a „Cartesian 3 axis robot“, but that’s only one part of the envisioned system. In a second step, develop a software model which controls the building blocks so they can interact in a meaningful way. Third: build the hardware, fourth: stitch together the software. Finally, commission the machine and have fun with moving around and storing all your small items. BTW: which kind of items are we talking about? I’m just curious …
True but it is still useful.
Sure it is, depending on the circumstances - which brings me back to the start of our conversation: under specific conditions, the idea to use a proxy (as per @Phaedrux' post) makes sense. BTW: in my printer, I just engage a static fan for this purpose - poor thing, it is heavily undervolted 
the chips do have a temperature sensor that can be referenced in code as a temp sensor.
Thermostatic control only works with the MCU sensor (that's what you do). The stepper drivers just provide a flag to signal overheating (when it's too late to start a fan).
I've just monitored the MCU temperature to decide when to run fans to cool the electronics.
That’s the proper way to compensate for high ambient temperatures. However, the boards not only suffer from external heat, they can generate a lot of ’steam’ themselves, especially the stepper drivers need to dissipate several hundreds of Watts. Since there is no direct means to monitor these chips, the bed heating may be a suitable indicator of the need for active cooling. Both approaches have their merits, but they use indirect measurements anyway, so the idea of providing some ventilation in general (especially on the back of the Duet) might be good compromise.
Just leaving 2 endstops at the Min of each rail . The 2 endstops are connected as a 1 single Endstop at the Min only. Will this work for Y-axis?
Yes - because, as you rightly say, the two endstops are wired to act as a single switch.
(1) For X-axis , only have 1 physical endstop at min or max
That's fine.
(2) For Y-axis, only have 2 physical endstops (connected in parallel) each per Y-axis rail both at min or max
Why? For each axis, you want to have one known position from where you then establish a coordinate system.
There are reasons to become confused:
For X-axis i have 2 endstops, one at 0(min) and other at 340 (max) ) but both are connected together to act as 1 single endstop
That's a problem: Endstops are a means to determine a physical location for an axis. If you can "home" the axis to two opposite locations, having both endstops wired together (i.e. in parallel), you are lost. Best is to just keep one endstop per axis.
I have already opened a similar topic on general discussion
Similar? Identical, with the extra 'bonus' that people willing to assist have to ask for all kind of infos twice just to understand your context.
thought it might be beneficial to ask here.
Definitely: No. Stay with your original thread!
@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.