@soare0 Finally, many thanks to Duet support. Honestly, I wanted to pay some support guys, as gcode scared me at first, and was mentally prepared to pay ... a good amount for this (more than I paid for DUET electronics). However, as I could not find any real paid support (albeit promised from one reseller), the forum (on the condition of reading the documentation, and some/many lost nights), was helpful enough.
However, I could not recommend this for anybody. I saw some failures here, for some who stretched too much with big projects, hoping to spare some money. But if learning is the goal, or needed skills are already there, this is a good place.
I heard here and there that DUET is too expensive.
It is not. Because of the best UNPAID support.

@fcwilt Yes, they are on the same subnet. I simply add or remove the AUX unmanaged switch, and no, no other virtual network created. Even if they would be, the port where I am adding or removing the switch stays the same, so it would be on the same virtual network, if that would be the case, wich it is not.
I mentioned that strange mention of the TIBBO boards (maybe you are not familiar with) of the same tier need, on the network, as like DX6, the protocols/management is an embedded software, and I think that some constraints may manifest in the drivers. A simple supposition.
On DHCP, if you have a conflict, it will not work at all, but if it works on different tiers, then... it works. I will test this, this month, and let you know.
And anyway, knowing of this behaviour, may help others too, but I do not see this as a problem. Maybe somebody more knowledged in networking will investigate and let us know the results.
I alșo will try another switch, with first occasion, however, right now, I think this was the last free switch in the house. Maybe it is there a problem, as this one is a small old 10/100 CISCO.

Al the best,
Paul

Fortunately, DM542 were on the original machine I am refurbishing, and the motors too, so tuned and wired.
RRF did a good job, but still, the motors would not move, even if the wiring was right.

The most needed change was R0, wich was not by default present, so the drives were locked at startup.
The timing is set so big, just to be ... cautious (as they did not work at first), it will be tuned later.

; Drives
M569 P0.0 R0 S0 T25:25:50:0 ; physical drive 0.0 goes forwards
M569 P0.1 R0 S1 T25:25:50:0 ; physical drive 0.1 goes forwards
M569 P0.2 R0 S0 T25:25:50:0 ; physical drive 0.2 goes forwards
M569 P1.0 R0 S0 T25:25:50:0 ; physical drive 1.0 goes forwards
M584 X0.0 Y0.1 Z0.2 E1.0 ; set drive mapping
M92 X80.00 Y80.00 Z400.00 E420.00 ; set steps per mm

I expected that R0 in M569 would be the default value, but it is not (and RRF does not set it anyway in config.g), so...

This is only an observation, not an issue (anymore).

@infiniteloop
Yes, this is a problem, but I think any interrupt, if not treated in time slots, like for a RTOS, has this potential.
Profane interest indeed, infiniteshowoff (δαίμονας)! :D:D:D
Bigger power for the heater then...
Thanks

In the following posts I will post details about the refurbisning process for my 3D printer. The goal is to help the ... somewhat beginners to deal with it, as even for me, with good background, it was a scarier experience, mainly because I did not had the needed time to dive into this, but I had an absolute need to make this printer work (or to throw it in a big garbage bin.

The printer was an enclosed 600x600x800, active heated, glass bed, dual head, DoWell DH8 printer.
It was as crappy as one can get, but not like the worst on the market, not by far. However, it was plagued by some stuff:

1. Crappy bearings and belts. Those I have not replaced yet, they are on the list.
2. Poor acces to service and repair
3. Zero acces to source code, wich was anyway incomplete, buggy but functioning... overall. Marlin flavour. Could not install on it a filament sensor (magnetic), or do any upgrades and tinkering. Support... 1 star from 10. Maybe 2 star, as they finally decided that this can be done, and offerend to sell me a BTT magnetic sensor at double the price, doubtfull functioning.
   Believe or not, this was the second reason.
4. The first was when, some evening, the board seems to be locked. I asked them, and they said, oh, they locked on time interval, for maintenance. WTF?
5. Cabinet heating. Now, that was some stuff. When printing PC, I needed to keep the door somewhat opened, but not too, as the cabinet fan was not a thermostatic fan, and the temperature could well exceed 75C, wich was bad for the printer, if not for the printed part.
6. Good printing heads, but HEAVY, and not properly cooled. To change them, it would have not been easily possible, as either I needed to CNC my own cooling system or to change the extruder for a water cooling system. To print PETG in summer (hot summer, no AC), it was almost impossible, as the filament would be softened because poor cooling of the extruder and throat. Why not being easily possible to change the extruder? Because ZERO acces to source code.
7. Do I need to say that at the first print, the hotend dropped on the part and triggered the bed collision system (wired in firmware with the filament over alarm, hehe...)

Good things:

1. Mechanical basically done
2. Wiring done
3. PSU ok
4. External drivers in place
5. The system, overall, was relatively well thinked, but the implementation lacked (still lacking) quality and ... the simple stuff wich make life easier. As I said to them, it is a pity they did not do what they could have done. I tried to point to them the weak points, first being the hotend dropping onto the part due to vibrations.
   This one was in fact an antologic event. I mean, the throat was completely round, and they tried to fix it with a M3 grub screw, overtightened. Guess what? It did not worked. How to explain to somebody notwilling to accept a mistake, that at least they could have used a pointed grub screw, and do that a ... M4, as the M3 was ... rounded from the factory.

And so on.
I still recommend such a construction. It will save a lot of work than start from scratch, but starting from scratch may have some advantages too. It is up to you. If you are able to start from scratch, for sure you do not need this topic at all.

I will start to post some images and code from the next post.

This way I hope I will repay the help received from this forum, wich really, really helped me.
This is why I chosen Duet in fact, for support. And because there were not real competitors on the market for my kind of printer and needs.
Initially I wanted to buy a BTT with Klipper, but thinking about ... oriental support, and they not having boards really suited for big printers, high temperature, thermocouples, external drivers, etc, I gave up to that alternative, wich is viable anyway.

Oh, and the most important: believe or not, God told me to choose Duet. He was right, I did the printer in no time... almost.
I am smiling now saying that, so you may take it like a joke, or like... my intuition, as you wish.
Right now, I think He would want me to ask from Duet team, to improve that filament sensor, but that may be only my personal wish

@soare0 I commented T0 in config, as the printer started by default (at power on) with the corresponding heather active.
I see the point. As a beginner in working with GCODE, I associated the tool with the heather in my mind.

@oliof Indeed, I noticed 3d printing and CNC machining need more brakets, haha...!
It was just unexpected, as Python is a foreign language to me (it always was).
No problem adapting though. If I survived to... some 3d printers, for sure I would survive missing some brackets...
Thanks again for your help.

@developeralgo222 said in Duet 3HC Expansion looses Connection:

Does that mean we have an issue with the way the CAN-FD is designed on the Duet Boards ? Does Duet boards have some protection designed in them to mitigate that issue ("undefined potential") as per your explanation above ?

Only optical insulation can provide this level of protection. This is usually done by optic fiber transceivers, and of course, optic fiber . These modules were not designed for such environments, nor they should/need to be. Except an human error, like in this situation, they should perform optimal, the way they are designed.

If CAN signal needs to be sent over long distances, and/or over big voltage differential, or in a really very, very noisy environment, only then such optical insulation is justified. In a machine like... most of ours, it is not the case. Working with 300kV (let say), for ozone generators, then we are talking another level, and then, those transceivers are justified.

Those undefined potentials, could very easy destroy some protection diodes, wich are calculated for a certain range, wich can be checked in chips specs. But the event ”happened” here, for sure surpassed the specs of the chips protection.

The interesting here is that the problem generated, can be (in appearance) very strange and inconsistent. One only can pray electronics boards to ”survive” after. In your case, you had not do it hard enough, if I may have a joke at this ”funeral”.

Sorry, but, no offence, I did not assumed too much. I myself done such stuff, so many more than once. Experience comes with a price ... usually.

L.E. The boards have a protection for common mode signals, L7, in a certain range of frequency.
However, adding a protection for what you would have needed, would mean (for example) some series resistors on the bus, to limit the current in the protection diodes (wich exists, inside the chips).
As the voltages may be relatively big (tens of volts or more, in this case with 2 PSU, without ground wire), the resistors should be in the range of (tens of?) kiloohms, wich would impair the speed of CAN so much, than it would not be usable for high speed communication (or even for low?), especially for somewhat longer cables, like 4-15m, as the parasitic capacitance will increase with length, but I suspect even for shorter ones it would be true.
Not to talk about adapting the bus (those terminators) in such a case...
In any case, nobody in the industry is doing such a thing, as it is not useful.

L.L.E. Isolating CAN Bus
One may jump directly to Conclusions, but the paragraph about Sources of failure, is a good read too

@MaxGyver For such machinery, I would double the firmware with true hardware limit switches (good ones, not toys) coupled with brakes, and whatnot, just in case. I noticed that infiniteloop already suggested, but better twice told than none heard, as I think this is not optional but mandatory, by any regulation at least ...

One of the things I needed, and because I decided to refurbish my printer (other than junky-closed-bugy electronics/firmware), was the lack of a magnetic sensor support.
I mean, in fact they (DoWell) had the possibility to use such a sensor on their cheap 32 bit board, but they did not mount such, because of the problems... you all know.

Long story short, I ordered the sensor from DUET, fortunately and unwillingly without its case (maybe this was a new version though?), so downloaded and printed LO-FI new enclosure.

I had great hopes, before reading the forums. Not so great, after some reading.
And... of course, it did not work.

Thing no. 0: do yourself a favour: print it in resin. I was very lazy, and also, I do not use my resin printer (albeit sometimes I should do), so I did it in ABS, 0.1mm height, 0.4mm width, 60mm/sec, on a raft. The raft was needed, because only a real hero would do such a print otherwise, on a 600x600x800, wich have 0.35mm on the height map (fine tuned, that is...). The smaller printers are garbage now, so, again, if one have such a printer and not being lazy, resin is recommended.

Oh, I would even buy some enclosures, well printed

Thing no. 1: the board was too close to the magnet. So needed to mount some washers for this. Message was: magnet too strong.
Right.
Then, amazingly, with some washers under the board, it worked. Somewhat.
I tried a complex printing, with many travels (even if short). So many errors, and please note that retractions were set low, 0.4mm, as I have a direct extruder.
Because of this, I then used some ... unreasonable settings: m591 d0 r30:200 e10.0
Why?
Because:

m591 d0

Duet3D rotating magnet filament monitor v4 on pin 1.io1.in, enabled, sensitivity 28.80mm/rev, allow 30% to 200%, check printing moves every 10.0mm, version 4, mag 131 agc 85, measured sensitivity 26.24mm/rev, min 36% max 109% over 649.0mm

I assumed that somehow, there are issues correlating what is happening there, especially with so many retractions (albeit low) and travels (albeit short).

I am not interested in filament skipping sensing, but in total throat blockages, because of sh.ty filaments. When you print 3-4 days in a row, such events are ruining your ... life.
Things worked well for an hour, or so, as in the beginning, it worked maybe for 30 seconds, with r60:160.

Then, the problems begun again.

This would be Thing no.2.1.

This time I tracked down to a mechanical issue: the magnetic rod had some movement along its axis, so the magnetic field strength, fluctuated, so... etc.
The problem was again solved, pressing a little on the center of the ... rotating piece (name it... your way please...), I mean in the hole of the body of the enclosure.

And yes, this was with my middle finger, the only one available in that position.

The sensor performed flawlessly in this time, but as I tested an ABS print, I preffered to sort this later, the test being concludent to me.

My point: the firmware works well, I mean for the board and for the sensor too. The problems are hidden in the mechanical assembly: it must be redesigned, to be immune to such stuff. For now, it is not. Maybe a bulky infrared rotary gap would solve the problem.

Or maybe I just moved too much, at some ... limit, the board from the magnet.

This would be Thing no.2.2.

As the first washers were 0.5-0.6mm, I put on some 0.3mm washers, and for now, it seemed to work.

This would be Thing no.2.3.

However, there was another issue, mechanical too: the sensor worked well only in a certain position. When rotating 90 dgr, clockwise, stopped working right. I assumed that maybe I inserted the PTFE tube too much, and I pulled it very little, I would say (during printing, again), unnoticeable.
It works now in both positions.

This is why many of us (ok, maybe not so many) love Tinkerbell (besides she has a very green and very short dress): she tinker until stuff works.

However, for an industrial design, I would say that rev. 5 (ish?) of this sensor would be needed.

And definitely threaded PTFE inserts, M5, or 1/8”, for pneumatics, or such. I even failed to understand how the... provided stuff works (the black ones): I just assumed one needs to push hard, and indeed, it was so, but I am used to pneumatics fittings, so...

For now, after:

m591 d0 r10:200 e10.0

is printing right.

And interogating:

Duet3D rotating magnet filament monitor v4 on pin 1.io1.in, enabled, sensitivity 28.80mm/rev, allow 10% to 200%, check printing moves every 10.0mm, version 4, mag 132 agc 58, measured sensitivity 24.87mm/rev, min 62% max 103% over 2219.0mm

You may find a very good ideea to use such ... relaxed interval, like 10-200%, at least until you know where you are situated with your printing/s.

@SpeedyDad
Maybe this helps:

; Drives
........
M569 P0.2 R0 S1 T5:5:10:0                        ; Z0 drive 0.2 goes backwards
M569 P0.3 R0 S1 T5:5:10:0                        ; Z1 drive 0.3 goes backwards
M569 P0.4 R0 S1 T5:5:10:0                        ; Z2 drive 0.4 goes backwards
M569 P0.5 R0 S1  T5:5:10:0                        ; Z3 drive 0.5 goes backwards
M569 P1.0 R0 S0 T5:5:10:0                        ; extruder drive 1.0 goes forwards
M584 X0.0 Y0.1 Z0.2:0.3:0.4:0.5 E1.0               ; set drive mapping
M671 X-70:-70:670:670 Y70:530:530:70 S0.5		  ; POSITION OF LEADSCREW FRONT LEFT, RL, RR, FR
M208 X0:524 Y0:600						  ; Xcarriage move, Ycarriage move

@SpeedyDad I configured mine like looking forward, as you normally work with the printer. However, you need to have the wiring right, and the mapping right, of course.
It worked ok.

@lazy_mosquito Indeed, I too used 1.5m for it, as it is a serial port (at first, I thought it is a SPI), and not even shielded, but of course, shielding (& etc) it is the best way to go. No SD, though.
Going SBC would solve it, but this may generate (really) unwanted problems for you. I am still reluctant (and lazy too) to try my PI5 with this.

@Triet Yes, this would be ok to do. BUT: I myself did not found a gcode to write in/a random file! I you find it, please let me know. So, for now, listing the events in console is the easiest thing to do.
However, as moth4017 specified, you should check on your pull-ups/downs, first.

@gtrider Yes, indeed, and they will do all of these, with their new 600x600x800 enclosed, active heated, glass bed printer, wich I heard is on presale today. I think it will be over in 1 hr...

@droftarts It is just normal, as our first planetary SG will be printed with a Duet powered printer... somewhere in the future.

@xXJRUSHMANXx When using external drivers, you only drive logically, no need to worry about current issues, I mean if they are set right in the external driver. Still, cant use quite an infinite number, as wiring capacitance will increase, and also current drawn by optocouplers (inputs) will increase too, but for a no of external drivers, it will do. Beyond that, use buffers. Beyond that too, get a ZPE.

I had one of these too, even if on rc3. I failed to get M122, maybe I will know more soon, but it was my first anyway. F,,,d my head and some of the print (at least is usable).
It is useful to have some anticrash sensor. I have one, but it was not enabled, and this was the result at 3am.
I found an error in z-height macro, wich I do not know how could have appear,
and also I ran a sound at part finish, both situation using a M98 to call some macro/file - do not know if related though.
The message in M122 (wich I had it but I lost it was that the printer could not home on X and Y, after print finishing). Still, why go down on Z, have no ideea, only if I will encounter this again maybe...

@travasky said in Chamber circulation fan control:

@soare0 The fans are DC, the chamber heaters are AC. But the bigger issue is that the chamber heaters will need to be controlled with a PID loop so there are moments when the fans would be off if the heaters are off. The air still should be circulating during the whole print.

Then add a small time relay (not mechanical, of course), set with the same period like your cicle, or such. If a little higher, will be no issue. I assume that something with a 555 will do, or even a simpler circuit. Probably you will find some little boards, wicj would do, like this one:

TIME DELAY

Probably needs adapted, and the SSR or whatever will replace the relay.
I hope I understood your needs, though... I would not use daemon.g but only for big cycles, like 1 min or more, and only if no other cheap choice, or reliable choice, but maybe I am wrong on this. Still, for sure it works with it.

@travasky A small DC SSR, anyway. If the fans do not need to be on at any other time than heaters on, than you may power them from the same heater output, vis this other DC SSR.