Pi4Duet3 DCS not started & Proximity inputs into IOx.in
-
That is the complete contents of M122 as far as I know. You may be able to capture more data using the debug mode. See here: https://duet3d.dozuki.com/Wiki/Getting_Started_With_Duet_3#Section_Monitoring_optional
I don't see anything in there but hopefully @dc42 will get a chance to take a look soon. It is a weekend though, so keep that in mind.
-
@Phaedrux Thanks for your input on that... It seemed to me that I had seen other M122 logs that had more info. That coupled with the message: "Response too long, see console" led me to believe I wasn't seeing it all, but that probably simply means to look in the Console, which is what I was already doing. Noob ignorance!!
-
@Phaedrux I'm getting a SPAM block when I try to send all I typed, so I've broken this up:
I have dug further and done some testing. As stated before, the Z proximity switch doesn't cause the fault, just X & Y. I did some testing with a meter (both resistance and voltage) and the three sensors all act in the same fashion. These switch as expected when metal is near, and each outputting nearly the same 24V (27.2) as is supplied, less a couple of tenths, when the sensor switches.
It appears that Spam detection is stopping my post when I include the dot between IO4 & in.
-
@Phaedrux One additional test: I plugged the P-switches into IO4in and IO5in with the same result: the DCS is not started. One final observation, the Diagnostic LED is flashing red about once per second with the P-switches disconnected, even though I have the inputs "Not Assigned". I'm hopeful that some of these details well shine a light on the issue... I'm befuddled. Thanks for your help!!
-
@dc42 Do you have any other thoughts on this challenge?? More info is listed in posts I made over the weekend.
Thanks!!
-
@BARN-Metal-Fab said in Pi4Duet3 DCS not started & Proximity inputs into IOx.in:
It appears that Spam detection is stopping my post when I include the dot between IO4 & in.
It's probably detecting it as a link and has determined that you don't have enough street cred to be trusted to post links yet. I've upvoted a few of your posts so hopefully that will give it a rest.
-
@Phaedrux Thanks for the cred assist... much appreciated!!
-
- Please provide a link to the datasheet or other info for the proximity switches. It sounds to me that they are PNP NC types - is that correct?
- Please provide a photo showing how you have wired the proximity switches to the IOx_IN connectors
- With the proximity switches connected and 24V power supplied, are you able to access the printer via USB and a terminal emulator program such as YAT?
-
Hi DC42... I'm working on the datasheet (P-switches were gifted by friend who's successfully used them to build this printer's older sister (Pi4 & Duet3). I believe these are NPN rather than PNP.
Photos will be forthcoming in about 5 minutes.
I have been successful in connecting to Duet3 with YAT (after powering everything off, then connecting with YAT, then powering everything up). I executed an M122... the results follow here (thanks tonnes for looking!)
M122<CR>
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956L2-G43S8-6JTDL-3S46L-1S2QD
Used output buffers: 1 of 40 (11 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 163100 of which 44 recycled
Exception stack ram used: 292
Never used ram: 75176
Tasks: NETWORK(ready,1980) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,5016) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:02:19 ago, cause: power up
Last software reset at 2020-09-02 22:10, reason: User, spinning module LinuxInterface, available RAM 76880 bytes (slot 0)
Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min 18.2, current 26.8, max 27.1
Supply voltage: min 0.4, current 27.0, max 27.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 0.0, current 12.1, max 12.2, under voltage events: 0
Driver 0: standstill, reads 25532, writes 11 timeouts 0, SG min/max 0/0
Driver 1: standstill, reads 25532, writes 11 timeouts 0, SG min/max 0/0
Driver 2: standstill, reads 25533, writes 11 timeouts 0, SG min/max 0/0
Driver 3: standstill, reads 25533, writes 11 timeouts 0, SG min/max 0/0
Driver 4: standstill, reads 25534, writes 11 timeouts 0, SG min/max 0/0
Driver 5: standstill, reads 25534, writes 11 timeouts 0, SG min/max 0/0
Date/time: 2020-09-10 14:37:59
Slowest loop: 3.85ms; fastest: 0.13ms
=== 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 ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -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 idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is ready with "M122" 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.
=== Network ===
Slowest loop: 0.47ms; fastest: 0.01ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
HTTP sessions: 0 of 8- Ethernet -
State: disabled
Error counts: 0 0 0 0 0
Socket states: 0 0 0 0 0 0 0 0
=== CAN ===
Messages sent 472, longest wait 0ms for type 0
=== Linux interface ===
State: 0, failed transfers: 0
Last transfer: 34ms ago
RX/TX seq numbers: 3681/3681
SPI underruns 0, overruns 0
Number of disconnects: 0
Buffer RX/TX: 0/0-0
ok
- Ethernet -
-
One further point RE: P-Switch assignments. While all three axes' P-switches are connected, I currently have them as "Not Assigned" in Driver config.
-
Here are three images to illustrate wiring:
1 - Duet & Pi Connections
2 - 24V (27.2) Distribution of power to P-Switches
3 - Proximity Switch Signal input to DuetSignal wire going only to IOx_in, 24+/- fed to sensors with terminal block (red-24+, blue-24-)
Thanks again!!
-
I believe I may need to correct the record on PNP v. NPN. With the switch closed, I get 0V between the -24V line & Signal. My reading of the attached image would indicate these Proximity switches are, as DC42 suggested, PNP devices. I interpret this condition to require Drive Mapping Endstop Pin in IO Mapping to set to Active-Low. I'm still working on a datasheet.
One additional thing I've tried: I now have the P-switch GND wire connected to the GND input to each of the IO1, IO2, and IO3 connectors, as shown below.
I have set the Config file Endstop Pin at two separate conditions for Drive X & Y: Not Connected, and IOx_in as Active-Low. In both cases having the P-switches connected to the Duet triggers a DCS not started error.
-
Hi All... still no joy on this problem. But I have a very strange anomaly/repeatability event... this actually happened a couple of weeks ago too when I was first trying to make this work, but I chalked it up to human error; but it's happened again. Here's the sequence:
- The machine had been powered off for 2+ days.
- The Y-Prox sensor was plugged into IO2 (similar to how it is pictured above, but X-Prox was not connected).
- I powered up and DCS started, and I could navigate DWC (thinking hurray... a thread).
- I powered down, unplugged Y-Prox from IO2, and plugged X-Prox into IO2).
- I powered up and got the DCS not started error (thinking OK... bad sensor).
- Powered off, plugged Y-Prox back into IO2 and powered up
- And I got the DCS not Started error (Damn!).
So, same connections, could navigate DWC, then after reconnecting that same successful connection under the same config (no changes), got the DCS not started error and can NOT navigate the DWC. On the off-chance that I had some kind of power stored and electronics were still maintaining some kind of state, I removed 110V power plug, bled the 24V supply by shorting terminals, and tried again: Same Story... DCS not started error.
I'm totally flummoxed!
Recommendations?? Do I have a bad Duet3? Replace the Proximity switches??
Thanks for reading!!
David -
Does it work correctly without the proximity switches?
Does it work correctly in standalone mode?
-
@Phaedrux Yes, when both X- & Y-Prox switches are disconnected, I do not get the DCS error, and can navigate the DWC.
I've not tried to run stand-alone (without the Pi). Is it as simple as unplugging the ribbon cable and powering up?? Since the touch screen is connected to the Pi, and I connect to the Duet via IP through the Pi, how would I be able to view the DWC, or that matter, even know if the DCS is started?? Connect with the microUSB and launch... what??
-
Standalone mode takes the pi completely out of the equation. I want to know if the proximity switches work correctly in that context.
You would disconnect the Pi ribbon cable, connect the ethernet direct to the duet3, and you would need a separate SD card with /www folder containing the DWC 3.1.1 files, and a /sys folder containing your config files from the pi /sys folder. You can make a copy of all those config files when you are connected to the DWC. select all the files and right click, download as zip.
Once the SD card is populated put it in the Duet3 and power it on. If the config.g has a simple M552 S1 in it, the Duet 3 should get a DHCP address from your router.
You can then connect to it via your browser on a PC with http://duet.local or whatever name you've given the device in config.g. Or get the IP address from the router.
-
@Phaedrux OK... I'll get started on this now. It may be tomorrow before I can post any results. Thanks!!
-
@Phaedrux Hi Again... I worked the problem this afternoon: Built the standalone MicroSD card, set the IP address, and fired up the machine. NOTE: It had been off for 23 hours. One of the P-Switches was connected to IO2. Results:
-I could ping the IP, and
-DWC was navigable.Turned off the machine, and turned it back on 10 seconds later. Results:
-No reply from a ping to the IP.
-DWC not reachable (of course)Turned it off, disconnected the P-switch, and powered back up. Results:
-Reply from ping.
-DWC navigable.Connected the other P-switch to the same IO2, and powered up. Results:
-No reply from ping, and DWC not available.
So... the answer to your question is: The system behaves in the same way in Standalone mode as it does in PiDuet mode. Further, the power being off for 20+ hours seems to have some strange effect that allows the DCS to start and DWC to be available on the FIRST power cycle only. The machine will fail 2nd power up cycle. Thus, it appears we have repeatable anomalous behavior (I suspect that's a contradiction in term).
Thanks again!!
David -
Ok thanks. That at least rules out a specific DCS/Pi problem and it's most likely an issue with the proximity sensor itself. Were you able to find a data sheet for it?
-
@Phaedrux I believe the following is the data sheet for the Prox sensors:
The previous file was empty. Here's the best I can do for a datasheet. It covers a range items in the same product line. Our sensor is highlighted in the PDF: LJ12A3-4-Z/AX Inductive Proximity Sensor Switch NPN DC6V-36V. Output Type NPN NC(normally close)
