@gloomyandy I'll have a look later today. It's somewhere within 3.4.x, and I can't update it easily because it has been built within a device binary.

I have a device running 3.5.x and yes the user position is updated to the next move / target position in the move queue.

Hello all,

I have a very peculiar issue where my daemon.g doesn't run during a G1 move.

var readoutTime = 0
var readoutDelay = 2500
var trimDelay = 250
if !exists(global.PID)
	global PID = 1	;fake PID. This is subtracted from the cutoff temperature as the lower turn-on temperature

while(true)
	if (1000 * state.upTime) + state.msUpTime > var.readoutTime + var.readoutDelay	;if millis is more than previous millis plus delay
		set var.readoutTime = (1000 * state.upTime) + state.msUpTime	;set the previous millis
		echo "Brightness: " ^ global.brightness
		echo "COBs_on is : " ^ global.COBs_on

	if global.COBs_on
		if move.axes[2].machinePosition != move.axes[2].min && move.axes[2].userPosition != move.axes[2].min
			set global.COBs_on = false
			echo "LID NOT DOWN"
		else
			M106 P0 S1
			M106 P1 S{global.brightness}
			if (sensors.analog[0].lastReading > global.cutoffTemp) && (state.gpOut[0].pwm > 0)	;if pwm on and over temp
				echo "Warning: Over temperature"
				M42 P0 S0
				set global.brightness = global.brightness - 1	;trim brightness by 1 pwm unit
			if (sensors.analog[0].lastReading < global.cutoffTemp - global.PID) && (state.gpOut[0].pwm = 0)	;if pwm off and undertemp, unkill
				echo "Turning COBs ON"
				M42 P0 S1
	else
		if sensors.analog[0].lastReading > 40
			M106 P0 S1
		elif sensors.analog[0].lastReading > 30
			M106 P0 S0.5
		else
			M106 P0 S0.2
		M42 P0 S0
	G4 P{var.trimDelay}

Points to note are that I have a +400W LED array that I am switching while the linear rail is at its minimum position (It's basically a big lid). I'm using the daemon to poll a global variable 'COBs_on' and regulate the temperature by trimming the PWM. The PCB can get to 70­°C at 85% duty! My main concern that if I accidentally send a G1 command, the lid opens up and the room is flooded with light.

To mitigate this, in line 14-16 I check for both user position and machine position and if either one is not at the absolute bottom, it sets the COBs_on flag to false. Now, this should work with move.axes[2].machinePosition, but I've noticed that the daemon only starts again until the lid is at the top of its travel...

Naturally, is there something I'm missing concerning the daemon? Is there a way of re-writing the G1.g command such that it switches the flag to false whenever a G1 command is called?

"echo move.axes[0].machinePosition" over console returns the previous position until the move finishes also, so it's not just the daemon that gets paused I feel.

Any help would be greatly appreciated
~ Q

Hello,

I have done a little bit of reading into the meta commands, and done some reading on the forums in regards to the counters. A little while ago there seemed to be talks of how to implement 'distance travelled' for maintenance purposes.

I have written a little workaround below, but would love to know if this is something that may be implemented in the future. The code below could be considered something akin to an .h file, that can be called just prior to a G1 or G0 command.

;begin

var x_dist = abs(move.axes[0].userPosition - move.axes[0].machinePosition)
var y_dist = abs(move.axes[1].userPosition - move.axes[1].machinePosition)
var z_dist = abs(move.axes[2].userPosition - move.axes[2].machinePosition)
var distance = {var.x_dist,var.y_dist,var.z_dist}

var odometer = fileread("odometer.csv",1,9,',')
while iterations < 3
	var i = iterations + 6
	set var.odometer[i] = var.odometer[i] + var.distance[i]
	if var.odometer[i]>999
		var.odometer[i-3] = var.odometer[i-3] + floor(var.odometer[i-0]/1000)
		var.odometer[i-0] = var.odometer[i-0] + mod(var.odometer[i-0],1000)
	if var.odometer[i-3]>999
		var.odometer[i-6] = var.odometer[i-6] + floor(var.odometer[i-3]/1000)
		var.odometer[i-3] = var.odometer[i-3] + mod(var.odometer[i-3],1000)

echo >"odometer.csv" "km:m:mm"
while iterations < 9
	echo >>>odometer.csv var.odometer[iterations]

;end

If anyone would like me to go over how this works, please let me know and I can post later, however my main concern (where I'm stuck and unsure how to continue) is how to implement this into a machine flow. Since I am using FFF, I have considered saving this as G1.g , and calling G0 at the end of it, but this falls down if one or more parameters haven't been called.

Ideally, I'm looking for an implementation of distance travelled, or maybe move.axes[].distance, or something similar.

If anyone has any ideas where I could utilise this then that would be much appreciated.
~Q

@droftarts Thanks for your quick response.

I just updated to 3.5 Candidate 2 and it seems to be working normally again! I didn't respond so soon because I realised I still need to use FFF mode for the time being.

-Q

Did you find a solution to this?

I am having the same issue. My solution has been to ditch CNC mode and run G1 for every move.

What a shame

Thanks for your responses. I have tried the above but have not had any luck.

I viewed forum.duet3d.com/topic/33314/6xd-external-driver-error-signal-handling which correlates to the issue that I'm having. I had an idea that a workaround would be using an I/O pin as an interrupt.

Is there another way that I can get the event handling to work using this error pin?

I am tempted to use a paperclip to trigger the pin while I'm still developing my config just for testing purposes but I don't want to damage my board. If the error pin is looking for a pin state, then would bridging to 5v or gnd trigger it?

Hi all,

I have read a few of the posts (and all of the documentation) but still can't figure out how to throw events on the 6XD.

Essentially, the setup is 2 servos with the following opto pinout:
STEP+ DIR+ EN+ HLFB+
STEP- DIR- EN- HLFB-

High Level Feedback (HLFB) is NC: When the servos are enabled, and within 10 counts of the commanded step, they act as a closed switch. If disabled or out of range, they are non-conducting.

I have wired them (sequentially - on DRIVER0 and DRIVER1 as parallel Y's) as follows:
+5V------------------ST+----DIR+----EN+
ST- ------------------ST-
DIR- ----------------DIR-
EN- -----------------EN-
ERR- ---------------HLFB+
GND----------------HLFB-

I have also removed the u/d jumper from the board and included a 330R resistor between 5V and ERR-, purely because I am a little lost in how to trigger error events on the board. The ERR- pin registers 0.32V and 3.4V. Is this above the logic level needed to throw an event?

I could run them without the error pins, but each are 350W and I'm aiming to move a gantry crane at over 4m/s, which would not be fun to clear up if an unhandled error occured!

There is definitely something small that I'm missing, so please let me know what it could be! Cheers, Q