Solved MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.
-
@mtcl said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
M574 X1 S1 P"io1.in+io2.in" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"io3.in+io4.in" ; configure active-high endstop for low end on Y via pin zstop+e0stop
Sine they are NO I think you'll need to invert the signal of those pins by adding a
!in front of the pin names like so: -
@mtcl said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
My endstops are in normally closed and they go in NO when they are triggered.
Hey, @Phaedrux They are in NC as i said in my post. Do i still put them as !? Eitehr way, in the M119 I dont see both endstop status, and even after triggering them, the status doesn't change in M119.
-
@Phaedrux said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
@mtcl said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
M574 X1 S1 P"io1.in+io2.in" ; configure active-high endstop for low end on X via pin xstop M574 Y1 S1 P"io3.in+io4.in" ; configure active-high endstop for low end on Y via pin zstop+e0stop
Sine they are NO I think you'll need to invert the signal of those pins by adding a
!in front of the pin names like so:On duet 2 wifi, there was a mapping for the motor pin with the endstop pin. Is it ok to define motors as 0:1 for x and endstop pin as 1 and 2?
-
I think your mappings look fine.
Can you send m98 p"config.g" to check for any syntax errors?
Also check your wiring for continuity.
You could also try simplifying and just map a single motor and endatop and test that first
-
m98 p"config.g" gives a green result.
- I recall there used to be led lights on duet 2 WiFi, are there lights on duet 3, do you know?
- I checked for continuity by testing each endstop individually. Each send stop works fine, it shows correct continuity when i engage it. Like i said it was working for with duet 2 WiFi.
- In the status i see a generic message about x end stop, not about x1, x2 endstop. Is there a way to split it?
- I'll try doing one end stop at a time like you said and report back.
-
What does a green result mean? Can you copy and paste the result?
-
-
Yeah there should be a reply like
12/10/2020, 11:52:26 PM M98 P"config.g" HTTP is enabled on port 80 FTP is enabled on port 21 TELNET is disabled Warning: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 365C Warning: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 463CAnd if there are any syntax errors in config.g they would show there as well.
It looks like you're sending it on mobile, can you use the full web interface and send it from the gcode console window?
Send M122 while you're at it for good measure.
-
@mtcl said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
My endstops are in normally closed and they go in NO when they are triggered.
Sorry about the ! suggestions before. I got caught on the NO part and glossed on the normally closed part. I'll blame that I was on my phone at the time.
The fact that M119 isn't showing a status change makes me think the wiring isn't making a connection.
-
I just tried the same from my macbook and also my windows computer, both gave out exact same output. Just a green message back like the mobile output was. Below is the output for M122:
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6HC version 3.2-beta4.1 running on Duet 3 MB6HC v1.01 or later (SBC mode) Board ID: <not sure if it is sensitive, so i hid it> Used output buffers: 1 of 40 (14 max) === RTOS === Static ram: 123292 Dynamic ram: 136876 of which 64 recycled Never used RAM 131960, free system stack 188 words Tasks: Linux(ready,101) HEAT(blocked,354) CanReceiv(blocked,947) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,49) MAIN(running,1175) IDLE(ready,19) Owned mutexes: HTTP(MAIN) === Platform === Last reset 03:18:04 ago, cause: software Last software reset at 2020-12-11 02:41, reason: User, GCodes spinning, available RAM 132232, slot 1 Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0xffffffff Task Linu Error status: 0x00 MCU temperature: min 19.4, current 19.7, max 20.8 Supply voltage: min 12.3, current 12.3, max 12.4, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 11.4, current 11.5, max 11.5, under voltage events: 0 Driver 0: position 0, standstill, reads 35790, writes 23 timeouts 0, SG min/max 0/0 Driver 1: position 0, standstill, reads 35790, writes 23 timeouts 0, SG min/max 0/0 Driver 2: position 0, standstill, reads 35791, writes 23 timeouts 0, SG min/max 0/0 Driver 3: position 0, standstill, reads 35792, writes 23 timeouts 0, SG min/max 0/0 Driver 4: position 0, standstill, reads 35793, writes 23 timeouts 0, SG min/max 0/0 Driver 5: position 0, standstill, reads 35805, writes 11 timeouts 0, SG min/max 0/0 Date/time: 2020-12-11 05:59:20 Slowest loop: 97.52ms; fastest: 0.09ms === Storage === Free file entries: 10 SD card 0 not detected, interface speed: 37.5MBytes/sec SD card longest read time 0.0ms, write time 0.0ms, max retries 0 === Move === FreeDm 375 (min 375), maxWait 0ms, bed compensation in use: none, comp offset 0.000 === MainDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === AuxDDARing === Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1 === Heat === Bed heaters = -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1 === GCodes === Segments left: 0 Movement lock held by null HTTP* is doing "M122" in state(s) 0 Telnet is idle in state(s) 0 File is idle in state(s) 0 USB is idle in state(s) 0 Aux is idle in state(s) 0 Trigger* is idle in state(s) 0 Queue is idle in state(s) 0 LCD is idle in state(s) 0 SBC is idle in state(s) 0 Daemon is idle in state(s) 0 Aux2 is idle in state(s) 0 Autopause is idle in state(s) 0 Code queue is empty. === CAN === Messages queued 0, send timeouts 59424, received 0, lost 0, longest wait 0ms for reply type 0, free buffers 47 === SBC interface === State: 0, failed transfers: 0 Last transfer: 18ms ago RX/TX seq numbers: 22635/22636 SPI underruns 0, overruns 0 Number of disconnects: 0, IAP RAM available 0x209d8 Buffer RX/TX: 0/0-0 === Duet Control Server === Duet Control Server v3.2.0-beta4 Code buffer space: 4096 Configured SPI speed: 8000000 Hz Full transfers per second: 35.01 -
@mtcl said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
M574 X1 S1 P"io1.in+io2.in"
Ok how bout just sending the M574 command in the console by itself. If there's something wrong with it, it should complain.
-
@Phaedrux said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
The fact that M119 isn't showing a status change makes me think the wiring isn't making a connection.
That's exactly what i thought. So i checked each wire again (even before this message). I will do a more thorough test again, most likely tomorrow. I mean if one endstop wire was loose it would make sense, how come all four of them are reporting it incorrectly, right? (that too after me checking each one of them for continuity). Is it possible that it is the beta firmware?
-
@Phaedrux said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
Ok how bout just sending the M574 command in the console by itself. If there's something wrong with it, it should complain.
I just did that, I got a green message back for that as well.
12/11/2020, 12:05:22 AM M574 X1 S1 P"io1.in+io2.in"
-
Are you clicking both endstops when you check M119 or just one?
-
@Phaedrux said in MPCNC: Duet 3 + SBC + Dual Endstop for X and Y axes.:
Are you clicking both endstops when you check M119 or just one?
I tried it both ways, but let me double check and try it again. Please gimme 2 minutes, i will run to garage and do this test and report back.
-
It would also be good to do the more basic setup of single axis and single endstop just to confirm things are working and then add the complexity.
There's also the SBC and Beta being added into the mix.
It might also be worthwhile to temporarily switch over to standalone mode to rule out the SBC being the issue. That would involve getting a new SD card and setting it up with the folder structure for the duet and copying your config files over to the /sys folder. Put the SD card into the duet, disconnect the SBC, plug the ethernet into the duet.
If that still doesn't work, could then upload the 3.1.1 firmware zip file to quickly check if it's a beta firmware issue.
Those are some things to check. For now though I must sleep.
-
Here are the two results.
First one is with both end stops depressed. Second one is with both released.
-
Thank you for the pointers. I will do these steps when I wake up myself. Your help is highly appreciated!
-
We're not crazy right? You have them wired correctly in your screen shot?
Duet 3: connect the switch between the IN and GND pins of your chosen IO_x connector.
-
That's absolutely correct. Only thing I can think of is the final white JST connector that is inserted into the duet may not be connecting properly?
I pulled them all out and will wire using individual ones and plug them in using more reliable black ones.
