@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!!

@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 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!!

@barn-metal-fab
Seems my post of the config.g did not work as I expected... here it is:
; Configuration file for Duet 3 (firmware version 3)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v3.1.4 on Thu Oct 08 2020 12:57:51 GMT-0700 (Pacific Daylight Time)

; General preferences
G90 ; send absolute coordinates...
M83 ; ...but relative extruder moves
M550 P"Duet 3" ; set printer name
M669 K1 ; select CoreXY mode

; Drives
M569 P0.0 S1 ; physical drive 0.0 goes forwards
M569 P0.1 S1 ; physical drive 0.1 goes forwards
M569 P0.2 S1 ; physical drive 0.2 goes forwards
M569 P0.3 S1 ; physical drive 0.3 goes forwards
M569 P0.4 S1 ; physical drive 0.4 goes forwards
M584 X0.0 Y0.1 Z0.2 E0.3:0.4 ; set drive mapping
M350 X16 Y16 Z16 E16:16 I1 ; configure microstepping with interpolation
M92 X80.00 Y80.00 Z640.00 E840.00:840.00 ; set steps per mm
M566 X3000.00 Y3000.00 Z250.00 E1000.00:1000.00 P1 ; set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00 Z1000.00 E4000.00:4000.00 ; set maximum speeds (mm/min)
M201 X1000.00 Y1000.00 Z50.00 E100.00:100.00 ; set accelerations (mm/s^2)
M906 X1800 Y1800 Z3000 E1200:1200 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S20 ; Set idle timeout; Trinamic Drive Tuning
; Tune tpwmthrs (V) so stealthchop runs at appropriate speeds
; and tune thigh (H) to avoid shifting into fullstep mode
M569 P0.0 V40 H5 ; X - Set tpwmthrs so StealthChop runs up to 105.5mm/sec
M569 P0.1 V40 H5 ; Y - Set tpwmthrs so StealthChop runs up to 105.5mm/sec
...
M915 X Y T20000 ; Set CoolStep threshold super low

; Axis Limits
M208 X0 Y0 Z0 S1 ; set axis minima
M208 X452 Y252 Z420 S0 ; set axis maxima

; Endstops
M574 X2 S1 P"io1.in" ; configure active-high endstop for high end on X via pin io1.in
M574 Y2 S1 P"io2.in" ; configure active-high endstop for high end on Y via pin io2.in
M574 Z1 S2 ; configure Z-probe endstop for low end on Z with active-high

;Filament Sensors
M591 D0 P1 C"io4.in" S1 ;Set Extruder "0" to Pin io4-in to indicate High when filament present
M591 D1 P1 C"io5.in" S1 ;Set Extruder "1" to Pin io5-in to indicate High when filament present

; Z-Probe
M558 P5 C"^io3.in" H2 F200 T4000 ; set Z probe to switch and dive height + speeds - active high (^io3.in ^=pullup resistor)
G31 P1000 X0 Y0 Z5.77 ; hold G31 P1000 X-5.35 Y-33.3 Z5.77 ; set Z probe trigger value, offset and trigger height. Set the Sensor X & Y offset from Left nozzle (Tool#0)
M557 X30:430 Y10:250 S20 ; define mesh grid

; Heaters
M308 S0 P"temp0" Y"pt1000" R2200 ; configure sensor 0 as PT1000 on pin temp0
M950 H0 C"out0" T0 ; create bed heater output on out0 and map it to sensor 0
M307 H0 B0 S1.00 ; disable bang-bang mode for the bed heater and set PWM limit
M140 H0 ; map heated bed to heater 0
M143 H0 S150 ; set temperature limit for heater 0 to 150C

M308 S1 P"temp1" Y"pt1000" R2200 ; configure sensor 1 as PT1000 on pin temp1
M950 H1 C"out1" T1 ; create nozzle heater output on out1 and map it to sensor 1
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit
M143 H1 S450 ;Set Tool 1 to max Tempt of 450C

M308 S2 P"temp2" Y"pt1000" R2200 ; configure sensor 2 as PT1000 on pin temp2
M950 H2 C"out2" T2 ; create nozzle heater output on out2 and map it to sensor 2
M307 H2 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit
M143 H2 S450 ;Set Tool 2 to max Tempt of 450C

											;CHAMBER HEATER

M308 S3 P"temp3" Y"pt1000" R2200 ; configure sensor 3 as PT1000 on pin temp3
M950 H3 C"out3" T3 ; create bed heater output on out0 and map it to sensor 3
M141 H3 ; Define heater h3 as chamber heater
M301 H3 P-1 ; Disable PID settings to use bang-bang
M143 H3 S120 ; set temperature limit for heater 3 to 120C
M307 H3 B1 D60 ; Set H3 to Bang-Bang and Dead zone to 60 seconds

; Fans
M950 F0 C"out4" Q500 ; create fan 0 on pin out4 and set its frequency
M106 P0 S0 H1 T45 ; set fan 0 value. Thermostatic control is turned on

;Set pseudo Fan7 to out7 to ouput 12V for powering timed relay
M950 F7 C"out7"

; Tools
M563 P0 S"Mosquito Main 0" D0 H1 F0 ; define tool 0
G10 P0 X0 Y0 Z0 ; set tool 0 axis offsets
G10 P0 R165 S205 ; set initial tool 0 active and standby temperatures
M563 P1 S"Mosquito Support 1" D1 H2 F0 ; define tool 1
G10 P1 X10.7 Y-0.2 Z0 ; set tool 1 axis offsets - Set Z to a -0.1mm height to adjust for hard limit on adjustment -- remove at carriage rebuild.
G10 P1 R165 S205 ; set initial tool 1 active and standby temperatures

;Pressure Advance
M572 D0 S0.85
M572 D1 S0.975

;---------------CUSTOM SETTINGS----------------
;M501

I've done a rebuild on our CoreXY running a RPi4 & Duet3. I built a new SD boot (I thought I followed instructions, but...). It seems I've not fully upgraded because an M122 shows RepRapFirmware ver3.1.1, but DWC is 3.3.0. Output from M122 as well as my config.g file follows below. FYI, I became aware of my problem due to a perpetual BUSY indicator.

I've run sudo apt-get update & upgrade commands, but everything reports up-to-date.

I'd appreciate advice on straightening out my problem. Thanks!!

M122:
=== 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 (13 max)
=== RTOS ===
Static ram: 154604
Dynamic ram: 163676 of which 44 recycled
Exception stack ram used: 512
Never used ram: 74380
Tasks: NETWORK(ready,1980) HEAT(blocked,1188) CanReceiv(suspended,3820) CanSender(suspended,1420) CanClock(blocked,1436) TMC(blocked,68) MAIN(running,4512) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:22:16 ago, cause: power up
Last software reset at 2021-12-08 19:14, reason: User, spinning module LinuxInterface, available RAM 74372 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 23.7, current 24.6, max 24.7
Supply voltage: min 27.0, current 27.0, max 27.0, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Driver 0: standstill, reads 44768, writes 0 timeouts 0, SG min/max not available
Driver 1: standstill, reads 44768, writes 0 timeouts 0, SG min/max not available
Driver 2: standstill, reads 44768, writes 0 timeouts 0, SG min/max not available
Driver 3: standstill, reads 44769, writes 0 timeouts 0, SG min/max not available
Driver 4: standstill, reads 44768, writes 0 timeouts 0, SG min/max not available
Driver 5: standstill, reads 44769, writes 0 timeouts 0, SG min/max not available
Date/time: 2021-12-08 19:42:07
Slowest loop: 4.40ms; fastest: 0.21ms
=== 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: 10, completed moves: 10, 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 = 3 -1 -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by HTTP
HTTP* is idle in state(s) 0 8, running macro
Telnet* is ready with "M122" 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 0, running macro
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.67ms; 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
  === Filament sensors ===
  Extruder 0 sensor: no filament
  Extruder 1 sensor: ok
  === CAN ===
  Messages sent 3773, longest wait 0ms for type 0
  === Linux interface ===
  State: 0, failed transfers: 2
  Last transfer: 15ms ago
  RX/TX seq numbers: 56967/57113
  SPI underruns 2, overruns 2
  Number of disconnects: 0
  Buffer RX/TX: 0/0-0
  === Duet Control Server ===
  Duet Control Server v3.3.0
  HTTP:
  Buffered code: G30 ; home Z by probing the bed
  ==> 24 bytes
  Executing macro homeall.g, started by G28

Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 39.55, max wait times: 11.5ms/0.0ms
Codes per second: 0.00
Maximum length of RX/TX data transfers: 3324/484
ok

config.g

Greetings All... I decided to cut the proverbial knot and ordered replacement Proximity switches ( LJ12A3-4-Z/Ax 4 mm Cylindrical Inductive Proximity Sensor Detection Switch NPN NC DC6-36V 300MA) on the bet that the ones I have were causing the problem. I received the order today and connected two of them to the Duet in the same fashion. The system powered up properly over several cycles. Victory!!

I consider this issue solved.

Thanks to everyone who supported me through this ornery problem... much appreciated!!

David

@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)

Inductive Proximity Sensor LJ12A3_Inductive Proximity Sensor_Photoelectric Sensor_Capacity Sensor_Solid State Relay_PCB Relay_Timer Relay.pdf

@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

@Phaedrux OK... I'll get started on this now. It may be tomorrow before I can post any results. Thanks!!

@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??

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:

1. The machine had been powered off for 2+ days.
2. The Y-Prox sensor was plugged into IO2 (similar to how it is pictured above, but X-Prox was not connected).
3. I powered up and DCS started, and I could navigate DWC (thinking hurray... a thread).
4. I powered down, unplugged Y-Prox from IO2, and plugged X-Prox into IO2).
5. I powered up and got the DCS not started error (thinking OK... bad sensor).
6. Powered off, plugged Y-Prox back into IO2 and powered up
7. 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

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.

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 Duet

Signal wire going only to IOx_in, 24+/- fed to sensors with terminal block (red-24+, blue-24-)

Thanks again!!