Ive started an Openpnp/Duet config/gcode page for the Openpnp group. Please help keep the page accurate and up to date. The current example is based off my current machine a CHMT36V using a 6HC and x2 1XD's.
Thanks Wayne

@dc42
Ok got comms sorted. I got this initially

Looks like the MISO line isnt pulled up locally on the the BTT board. I guess this makes sense as the board is meant to plug into 'step stick port' on a BTT driver board. In all the literature I read from BTT/Biqu makes no mention of pullups or active line jumpering. Any way pulled the MISO line up to 3V via 10k and now I get the following;

DWC is also reporting semi resonable values so now just some tuning and firmer wiring to get the ball rolling. I have a Duet PT100 dtr board coming from filastruda and I dont think ill have it for a week. I also ordered an Adafruit MAX31865 bob that should be here tomorrow so Ill follow up this thread on how that gos.

Huge thanks for this Forum and support, the best

@Phaedrux "You MIGHT be able to get away with longer length if you used a shielded twisted pair cable instead of a flat ribbon, but even so, SPI isn't meant for long runs."

I dont think shielding will help. The issue is increased capacitance and resistance with long wire runs and screws up the spi signal timing. The quickest check would be what others have suggested. Simply move the SBC closer to the 6HC using the original cable. If that fixes your issue no amount of shielding is going solve your problem. You will need to relocate the SBC next to the 6HC.

@owend
Will do, I need to get the mechanicals back together first.
If you dont know what this is, it's the aftermath drag pin machine crash. The pin with the bent tip slides up and down within the blue coil of the selenoid with the bent frame.

I hope to get fixed tonight and put some of my new and improved RRF commands to work

Thanks again.

@fcwilt THANK YOU! The schem answers all questions.
For my app I will drive an off board FET driver board via V_OUT's set to 12V.

@infiniteloop
Thanks. The issue I've had has been in regard to reseller sales/shipping itself and not Duet itself or 2ndary integration. Duet is without peer, and I have 7 different production machines using Duet controllers. I'm located in USA CA and have attempted to use a CA based vendor twice for Duet and each time the order has been filled incorrectly. This is extremely frustrating. Conversely, I started using Filastruda located on the opposite side of the country in GA. Ive had 6 different Duet orders with Filastruda with no issues and have received the orders much quicker than the CA base vendor.

This is just my experience and I don't know if posting this is of any help to anyone else.

...end of rant.

Just an Fyi re the new M260.2/M261.2 commands in RRF 3.6. I was stuck for a couple days trying to leverage the 6HC Aux comm port to get/set parameters of a foc motor and report them back to Openpnp via the Main comm port.

Im sending/receiving data on the Aux port as;

M260.2 P1 B{0x52, 0x5A, 0x0D}
G4 10
M261.2 P1 B6

The expected Rx data on the Main port is simply a byte array;

{0x5a, 0x65, 0x72, 0x6f,0x3a, 0x5a}

M261.2 indeed reports the data to the Main comm port, but is prepended with" Received (hex) " and the rx bytes are space seperated; ' ' ;

2024-11-25 22:38:29.200 GcodeDriver$ReaderThread TRACE:
[GcodeAsyncDriver:COM13] << Received (hex) 5a 65 72 6f 3a 5a

This needs to be understood, but not explicitly stared in M261.2 if anyone is planning to parse the rx data as one would using regex. For my application the regex

^.*( [0-9a-f]{2}){5} (?<Value>[0-9a-f]{2})

Groups the correct Value for me.

Any rate the new commands work great now that I understand the output.

Just an Fyi re the new M260.2/M261.2 commands in RRF 3.6. I was stuck for a couple days trying to leverage the 6HC Aux comm port to get/set parameters of a foc motor and report them back to Openpnp via the Main comm port.

Im sending/receiving data on the Aux port as;

M260.2 P1 B{0x52, 0x5A, 0x0D}
G4 10
M261.2 P1 B6

The expected Rx data on the Main port is simply a byte array;

{0x5a, 0x65, 0x72, 0x6f,0x3a, 0x5a}

M261.2 indeed reports the data to the Main comm port, but is prepended with" Received (hex) " and the rx bytes are space seperated; ' ' ;

2024-11-25 22:38:29.200 GcodeDriver$ReaderThread TRACE:
[GcodeAsyncDriver:COM13] << Received (hex) 5a 65 72 6f 3a 5a

This needs to be understood, but not explicitly stared in M261.2 if anyone is planning to parse the rx data as one would using regex. For my application the regex

^.*( [0-9a-f]{2}){5} (?<Value>[0-9a-f]{2})

Groups the correct Value for me.

Any rate the new commands work great now that I understand the output.

@dc42
SPI success! Before unwinding everything, I took another look at the git repo and spotted LISAccelerometer.cpp had been updated after my other file update. I updated that file and everything compiles for LIS3D on SPI.

Ill mark this question as solved once I confirm HW function. I have the chip carrier for the SAME5 on order but probably won't rec for a couple weeks. I may just order the PCB regardless as I need the machine back up and running and the accelerometer no critical for its fxn.

@wayneosdias
Unwinding my SPI and I2C changes I see a change that I didn't make that I should have:

//**REMAPP**//#  define ACCELEROMETER_USES_SPI			(0)				// accelerometer is connected via SPI
/**REMAPPED**/#  define ACCELEROMETER_USES_SPI			(1)				// accelerometer is connected via SPI

I tried that but still errors. I still plan to unwind everything and go back to I2C

@dc42
Hi David, I didn't change the #define SUPPORT_SPI_SENSORS 1, but I did change quite a bit of the file. For the sake of completeness I attached my full config file. I've tried being very explicit of my flagging changes by prefacing changes, eg;

//**REMAPP**//constexpr size_t MaxPortsPerHeater = 1;     
/**REMAPPED**/constexpr size_t MaxPortsPerHeater = 0;

I don't expect you to comb thru my full config, but if you do take a look and see anything off it'd be great if you let me know

Meantime Ill revert the LIS3DH back to I2. I only made that change as I prefer SPI to I2C. But if SPI is causing probs and hasnt been tested then Ill go back I2C.

Thanks again

EXP1HCL.h

@dc42 I updated the LISAccelerometer.cpp and now getting the following errors:

Im reconfiguring 1HCL 3.5FW for a custom board. I want to use the LIS3D on the SPI PA(15-19) of SAME5x , no other peripherals on the SPI bus. Heres part of my .h config;

#define SUPPORT_SPI_SENSORS		1
//**REMAPP**//# define SUPPORT_I2C_SENSORS	1
/**REMAPPED**/# define SUPPORT_I2C_SENSORS	0
# define SUPPORT_LIS3DH

#if SUPPORT_LIS3DH	
#  define ACCELEROMETER_USES_SPI			(1) // accelerometer is connected via SPI
constexpr Pin Lis3dhCsPin = PortAPin(18);		     // same as encoder CS pin
constexpr Pin Lis3dhInt1Pin = PortAPin(12);		    // same as io1.in

# endif

// Shared SPI (used for interface to encoders, not for temperature sensors)
constexpr uint8_t SspiSercomNumber = 1;
constexpr uint32_t SspiDataInPad = 3;
constexpr Pin SSPIMosiPin = PortAPin(16);
constexpr GpioPinFunction SSPIMosiPinPeriphMode = GpioPinFunction::C;

constexpr Pin SSPISclkPin = PortAPin(17);
constexpr GpioPinFunction SSPISclkPinPeriphMode = GpioPinFunction::C;

constexpr Pin SSPIMisoPin = PortAPin(19);
constexpr GpioPinFunction SSPIMisoPinPeriphMode = GpioPinFunction::C;

Im getting a bunch of errors

Any help on clearing this up? Thanks!

@dc42 understood, thanks

@dc42 @jay_s_uk
Thank you and understood re EXINT.

Is there any considerations for reassigning the '.ate' pins?

Lastly, I thought I read somewhere the io0.in/out UART wasn't available on the Expansion boards yet. I see in 3.5 1HCL

// PB02 IO0 out, UART available
// PB03 IO0 in, UART available

and the io looks to be wired to sercom5d. Is the Duet Aux UART available on the expansion board?

Thanks for the help

I'm creating a custom board based off the 1HCL and remapping some of the io.
In the PinTable what is the 'Exint'? Im guessing the IRQ priority?

	TC			TCC			ADC			SERCOM in		SERCOM out	       Exint     PinName
	// Port A
	{ TcOutput::none,	TccOutput::none,	AdcInput::none,		SercomIo::none,		SercomIo::none,		0,	"spi.cs1"	

Also what is 'ate.'? Im unfamiliar with this prefix.

"ate.v12"		},	// PA06 12v monitor

Thanks for any help

Updating my previous toolchain from 10.1 to 13.2 fixed the problem and is compiling,
Thanks Guys