Dual nozzle head homing with Duet/RRF

[JW]

Hi all, finally getting around to building a machine and using OpenPnP; my head design is a spur and dual rack design, much like the 'Peter's Head'.

There seems to be quite a lot of conflicting information about how to home these, how many limits switches are required, whether the limit switches should be end of travel, mid travel etc.

I'm looking for a bit of guidance, specifically if there are any traps when using Duet 3D 2, and RepRap firmware.

The question I'm really stuck on, if I have a single limit switch that triggers when the dual nozzles are in their balanced-Z heights, when I home, how do I/openPnP know which way to drive the motor? Presumably when the machine starts up, I can't just drive x number of steps in one direction blindly, without hitting the mechanical limits of the system?

Many thanks!

[Wayne Black]

Im running duet rrf and a peter head. First Duet is THE best motion controller Ive used for non cnc use such as openpnp. 

For peter head;

-For dual head use single limit switch located at max travel, not mid travel. Empirically/manually find mid/balance point for both heads w Z motor disabled, this is 0. Now enable Z motor, run nozzle to max limit noting travel. In the homing script move the nozzle (-) travel noted previously to set the dual head to balanced/0 position. Note this should be done wo tips loaded or in a spot where clearance will not be an issue.

-For Openpnp use the negate transform, from there openpnp takes care of everything else. for you

[JW]

That's great, thanks very much - just ordered the Duet! Actually ordered the Duet 2, with expansion board and my main XY steppers are closed loop steppers, so I need to feed them with the raw STEP/DIR/EN signals etc.

What you say makes perfect sense, so the limit is at max of 1 of the nozzles, and you just always drive in the direction that tends towards maxing out the nozzle with the limit switch on, then once the switch is reached, step back n number of known steps to achieve the balance point?

Alternatively, is it possible to home using an analog voltage? I have a dual shaft stepper that I can drive a D shaft through hole pote tiometer with.

Is it possible in the homing script to say "if head position voltage <2.5V, drive clockwise til 2

5V, if >2.5V drive CCW til 2.5V?

This would be nice, as if there was a power failure with a nozzle down, the machine could not recover without potentially crashing a nozzle in Z...

[Wayne Black]

Im not familiar with Duet 2, but have 5 diff machines running Duet 3 boards. All Duet 3 have CAN FD expansion for off board drivers and the Mini5 has native x2 native step/drive outputs. My pnp is running a 6HC and x2 CAN expansions for offboard XY closed loop drivers. I also have Duet 3 closed loop drivers, but have never used them as my current set up is pretty great. The Duet CL drivers are likely far more tunable than the cheap Chinese CL drivers, but they just work and I haven't had reason to replace them.

Re ratiometric fb for Z position, that's a great idea if you are worried about black/brown outs. And yes, what you describe above would be easy to script in Duet rrf. There is one thing about the Duet stuff, even though they claim serviceability for all sectors including CNC and such, it is all still very much geared toward 3d printing. That said...

...Like your desire to use analog FB for position sensing, you would likely use a Duet 'temp' input. This is all fine, but a hidden issue within RRF is a very slow sample rate for temp measuring (I dont recal what the freq is, but no good for say probing). This may not be an issue if you're just trying to determine at stable state of the head at power on, but for dynamic positioning you would need to use the Duet probe feature. There is only 1 probe input on Duet, there's multiple "temp" inputs on board which is also expandable to off board sensors.

Again, all super easy to do things you describe in Duet. Ive created some pretty random stuff w the Duet and its be by far the easiest most flexible controller Ive used.

[JW]

Really useful feedback again, thank you.

I had actually missed the external driver output on the Duet 3 Mini5, which was what caused me to order Duet 2. Just switching the order now however as the Mini5 is lower cost than the Duet 2.

Having spent the majority of my career in automotive and industrial embedded hardware and firmware development, this is my first step into using configurable DIY type controllers, so need to get my head around how the scripting systems work, access to IO etc without intimate knowledge of the system's architecture.

For example, I don't even know yet whether my heads homing script runs on the Duet and is called by OpenPnP via an G code, or whether OpenPnP executes the homing sequence via a series of G codes, plus some M codes for things like switch state retrieval.

I've already got the limit switch in the head design, so I'll throw in the potentiometer too and wire it all up so I've got both options.

[Wayne Black]

Good, Duet 3  leverages a better form of RRF. The Mini5 is ok and I have it in a couple machines but I find the wifi is not as stable as 6HC ethernet which is rock solid. The newer 6HC has either wifi or ethernet. Its not much of an issue since wifi is only for configuration and DWC interface, not motion planned process sending.

Scripting in Duet is super easy with the Duet Web Control (DWC). Via DWC you can easily create and modify macros (duet nomenclature) that are saved directly on the Duet SD. Once a macro is created it can be called anytime with a RRF M code with the macro name as the parameter. These macros can be conditional and can also leverage global vars also stored on the SD. Pretty slick :)

Scripting in Openpnp is easy enough im sure, but Ive never done it. I find it easy to create an 'actuator' in openpnp and openpnp uses the actuator to call the custom duet macro.

Homing is kinda hybrid. Duet performs machine homing via an Openpnp home call. Once the machine is homed Openpnp performs vision homing if you have a down looking camera. A down looking camera is a must as all offsets are referenced to the down looking camera position.  

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/084be7bd-f129-4628-b1c2-88379303f3bbn%40googlegroups.com.

--

Wayne Black

Owner

Black Box Embedded, LLC

black...@blackboxembedded.com

1.831.682.4964

[JW]

The Mini 5+ is ethernet too, which is what I've gone for; I personally steer clear of WiFi when machinery is involved, it always ends up being a headache *somehow*, in my experience.

The architecture you describe of calling macros with M codes is exactly how I was hoping it would work. Thanks again for your steer/guidance, very useful at this stage...

[JW]

Oh and yes, up and down cameras both accounted for...

[Wayne Black]

WIth your background you should find this all very linear and easy to learn the duet/rrf workings. The hal is all taken care of by Openpnp gcode driver setup and regex. Should be fairly obvious to you :)

For whatever reason you do exp any issue w Duet, the Duet forum is very active and helpful. DC42 (David Crocker) is one of the moderators and co creators of the Duet line. He's on the forum daily, regardless, the forum is full of duet super users.

[JW]

Thanks, will check out the forums - that's one of the factors that drew me to the Duet range over other common controllers, the documentation appears much more complete, and so with a solid community too hopefully it'll be relatively plain sailing.

Should have the machine built in the next fortnight or so.

All the best

[mark maker]

Bit late in the discussion.

A mid-homing switch is usually very simple: there is a bar on one of the nozzles that presses on a switch whenever the nozzle is down or up. So the polarity of the switch tells the controller which way to move to balance when homing. Can't say whether Duet can do that, but would be surprised if not. Controllers usually work like that way anyways, in case the machine got powered up with the axis on the limit, i.e., the homing switch already being pressed.

In this scene (hope it animates) you barely see the black shiny bar and how the switch works (credit Mike Menci's machine):

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7e3dc473-80c8-41dc-ac1b-2db6d07fba81n%40googlegroups.com.

[Wayne Black]

Agreed, Mark :)

I guess it depends on your form factor needs. In my case the head needs to be as narrow as possible so fitting the switch at max stroke keeps the head narrower. It also easily allows for a fine tuning grub screw.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/db713403-8b43-42ab-b567-bc3282dd2191%40makr.zone.

[mark maker]

Just be aware that homing to max requires the head to be somewhere in X/Y where the other nozzle doesn't ram into the table (this one is "homing to min" so to speak). Conversely, you can't home X/Y first, as you might have one of the nozzles extended down and it might collide with an obstacle.

When powering up the machine in any state (perhaps after a mishap), this will usually require manual care, i.e. repositioning the (unpowered) head in X/Y by hand or by jogging etc. before initiating the homing cycle.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABUTZN_7LNzkDHVPPJv8fmJirix3dDsCM1dkV%3DcJcAhiLcU-7w%40mail.gmail.com.

[Wayne Black]

Agreed again Mark,

Thats what's intriguing about JW's ratiometric position sensor idea. Using the feedback as an Openpnp Axis Lock when outside of designated parameters.

[JW]

This is interesting food for thought; and given the firmware support is clearly there for limit switches, but potentially not for using an analog position feedback without resolving sampling rate issues, I think there's a cleaner solution.

If I understand what you've shown Mark, there's 2 limit switches - and end switch, and a switch that determines if the nozzle is 'too high' or 'too low'?

Just concepting a small PCB with a concentrically driven through hole potentiometer, driven by the dual head Z motor, with some very simple circuitry to output 2 digital signals; 1 to indicate whether the motor is 'away from home' clockwise in terms of motor direction, or CCW, and the 2nd signal to go high when homed.

Essentially achieves the same as 2 switches, in a more compact head design.

[JW]

Or, is it simpler than that Mark? Are you homing with a single mid travel switch, and depending on the initial polarity of the switch's signal, you know which way to drive to approach mid travel, then you stop at the state change of the switch?

[Mike Menci]

Homing 4 nozzles with 2 switches : https://www.youtube.com/watch?v=CbqQ_7yrL24

It works great for years now, if anyone has doubts! 

Mike

[Wayne Black]

"Or, is it simpler than that Mark? Are you homing with a single mid travel switch, and depending on the initial polarity of the switch's signal, you know which way to drive to approach mid travel, then you stop at the state change of the switch?"

I think the video that Mark shared is not a fair comparison to a peterhead. His posted video is showing a lead screw set up so the dual nozzles simply cant be tied together. Or at least not any conceivable way I can think of.

IIRC your using a dual pinion rack pinion set up correct? You only need single limit for both nozzles and you can put the limit switch mid or max position. Regardless mid or max switch placement for a true dual nozzle rack pinion (peterhead) you only need 1 limit for both nozzles. Again Openpnp transforms the 2nd nozzle.

A pro for mid position is that after a power out or at turn on if the switch is triggered, you know the head (both nozzles) are at safe position effectively turning off Axis lock within Openpnp that prevent crashes. If on the other hand the mid switch is not triggered you have no way of knowing which way is safe to balance the nozzles. Here is where your ratiometric approach shines. The analog approach tells you which way to drive the nozzles to balance the head.

I did a quick search for the duet temp sample rate, 4Hz. Again 4Hz is perfectly fine for stable state detection. If you need higher sample rate here is a thread I started about this on the Duet forum, you can see DC42's response here

Skipping ahead to the answer. You can basically use the probe input or you can use a atd/spi chip. The former would be preferable if you dont need the probe input for anything else, the latter if you need multi-channel atd measuring >4Hz

[mark maker]

It just seems too complex, and there is certainly no support in OpenPnP.

Another way is just adding a spring that balances the nozzles. Power off motors, let them snap to balance, power on, make a controlled small move off balance, power off again. Maybe add one or two more such iterations. With each iteration, relaxation will be from a more precisely known position and result in a repeatable balanced homing position.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ed3763c2-903e-437f-8f5a-d5fcf809811bn%40googlegroups.com.

[mark maker]

> Are you homing with a single mid travel switch, and depending on the initial polarity of the switch's signal, you know which way to drive to approach mid travel, then you stop at the state change of the switch?

It is not my machine. It is Mike Menci's. He has a Smoothieware controller and I made a fix in that firmware to allow for mid-homing. I don't think Duet has this problem.

I think there is only one switch, and yes it works as you describe, with a second iteration to be more repeatable and precise (as seen in the animation).

Once you have the reference homed position, you can add soft-limits usually both on the controller side and on the OpenPnP side (those slightly narrower) to prevent excessive Z motion. Sometimes there are also hard mechanical limits. The Z motor is usually weak (to be light), so it would simply stall against the limits.

But you should be aware that the real danger lays with (fast) sideways X/Y motion that crash into obstacles that are in the reachable Z range of the nozzles. This can happen during setup of the machine, when homing is not yet setup correctly, when using manual jogging or when coordinates of nozzle tip changers, feeders etc. are not yet right. Once in production the problem goes away, all coordinates are correct and preprogrammed motion is always going to Safe Z first.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/221d95cd-79b6-45a9-9e43-67c51fd02cddn%40googlegroups.com.

[mark maker]

> I think the video that Mark shared is not a fair comparison to a peterhead. His posted video is showing a lead screw set up so the dual nozzles simply cant be tied together. Or at least not any conceivable way I can think of.

Like I said it was Mike's old head. I don't know how he negated the other nozzle.

But this is irrelevant. Any type of "Peter's head" (negating shared axis) can have such a bar mounted that presses on a switch from the mid-position to one side only. Alternatively, make an optical light-weight variant.

Obviously the analog feed-back works too, but then why not just add a trimpot+comparator, and you get the same deal (one side down = 0 the other down = 1). No added complexity in the controller or in OpenPnP.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/11b6f416-0724-4e91-aec4-0b95b03bcb9an%40googlegroups.com.

[Mike Menci]

This is from 2018 when I started myPnP as a desktop version... 
See attached how it used to be from parts I had in my stock + garbage.. 

[Mike Menci]

Hello Mark, 

The other nozzle pair has 2nd switch and it works just like the first pair.  No X or Y movement is possible if  Z and Z1 axis & the nozzles are not homed first - done with config.txt file -Smoothie.  Due to complex and limited space in Head Box -this two LS are triggered at the top of the Head structure 

Dwg -picture enclosed. 

On Sunday 14 April 2024 at 10:56:36 UTC+2 ma...@makr.zone wrote:

[Wayne Black]

Another way is just adding a spring that balances the nozzles. Power off motors, let them snap to balance, power on, make a controlled small move off balance, power off again. Maybe add one or two more such iterations. With each iteration, relaxation will be from a more precisely known position and result in a repeatable balanced homing position.

That worked great on my seesaw head but seems very impractical with a peterhead IMO.

Like I said it was Mike's old head. I don't know how he negated the other nozzle.

Sorry wasn't familiar w Mike or his machine. I was just going of the limited clip you posted. I guess you can drive a dual negative head using a lead screw by a pinion gear :) Im sure it was incredibly slow and why he went on to using belts...

Obviously the analog feed-back works too, but then why not just add a trimpot+comparator, and you get the same deal (one side down = 0 the other down = 1). No added complexity in the controller or in OpenPnP.

Agreed Mark. Analog FB wouldn't add any complexity in OpenPnP though IMO, just set up as an actuator w axis lock. Only consideration being on the duet /rrf side re sample rate.

He has a Smoothieware controller and I made a fix in that firmware to allow for mid-homing. I don't think Duet has this problem.

In duet/RRF limits aka 'endstops' are configurable as min or max. I dont see anything re midpoint detection. The gcode for endstop config is M574 which you'll need to review when you set up your machine

The other nozzle pair has 2nd switch and it works just like the first pair.  No X or Y movement is possible if  Z and Z1 axis & the nozzles are not homed first - done with config.txt file -Smoothie.  Due to complex and limited space in Head Box -this two LS are triggered at the top of the Head structure 

Well done Mike! My head is very similar, albeit only 2 nozzles, single limit top/max of nozzle 1. The OP is trying figure out how to handle nozzle state at power on and black out situations. If I understand your machine setup correctly XY is locked until Z is homed.  Z homes regardless of potentially having a tip loaded and interfering with table, correct?

To the OP. You can't know exactly the nozzle state at power on/reset without added complexity on the peterhead vs say the seesaw head. Care must be taken that the head parks in a 'safe' zone and that tips are unloaded when not in use. The great thing about the peterhead is greater torque and travel that makes auto tip changes easier than the seesaw head.

Going forward if you want to add a 'safety' switch, Mark is right, any optical/inductive/mech sensor slightly off mid point of travel would tell you which way to drive the nozzles to a balanced position this would be very straight forward in both Openpnp and duet/rrf.

[Mike Menci]

"Im sure it was incredibly slow"   - this is relative - depends on the pitch of the lead screw witch was in my case 5mm /rotation I think... So it was not so slow - I don't recall if I tested it full speed. The Z stepper motor hight (-over the top )was the reason and the gear with Pinions had some gap ... but this all was hand made - not much machining involved in assembly on main Head plate beck in 2018... 

My nozzle changer is RC servo operated - still not in perfect condition - but a short video here: https://www.youtube.com/watch?v=kQ9cqHOH0Uc&t=7s

https://www.youtube.com/watch?v=7UKq3CRtNf4

About Z homing and preventing move if not Homed - have a look here if you are interested: https://groups.google.com/g/openpnp/c/Xo5o8r5BkKA/m/P5_P-QunAgAJ

[JW]

Oh dear, now I just replied to blackboxembedded directly, not posted on here. Wow Google groups gets messy fast with all these repeated auto-copies of the thread above, or is that me being a moron and causing that?

So, I've got a stepper and 2 switches hooked up the Duet in front of me on the bench, and have written a homing script in RFF that runs against the end stop switch (which is me pressing the switch right now, whilst the parts for the machine are being manufactured), and this works fine. Motor stops then changes direction to go back to a simulated mid position.

However, as you'll see from my post on the Duet forums (https://forum.duet3d.com/topic/35452/reading-general-purpose-inputs-in-duet-mini-5-returns-null?_=1713114595113), I'm still wrapping my head around the RFF object model, and trying to read that second switch, to enable me to use that switch to know which way to start homing in the 2 switch concept discussed above.

[Wayne Black]

"Im sure it was incredibly slow"   - this is relative -

Very true! In the case of lead screw vs timing pulley you must admit the belt/pulley will surely be faster in all practical aspects for pnp. Not as precise though, again relatively speaking :)

My nozzle changer is RC servo operated - still not in perfect condition

I saw that video right after I bought the deltaprntr magazine. I wished I had seen your video first as I wouldnt have bought the magazine. The magazine stand is too tall form my machine so I need to redo the base and I plan on using pneumatic actuation. I thought it wasn't a total loss, as I can reuse AL top plates, but the machining is pretty poor on them and thinking of scrapping the whole thing. My CNC is down currently, so I may just print out an option like yours. Well done :)

[Wayne Black]

However, as you'll see from my post on the Duet forums

Lets track this down via the Duet forum, cya over there...

[JW]

I would... except, it seems I don't have a reply button or anything over on the Duet forums, there's not some odd rule is there where you have to have n number of replies before you can reply to your own post?

[Wayne Black]

I would... except, it seems I don't have a reply button or anything over on the Duet forums

Really? Thats unfortunate, a lot of smarter guys than myself re this stuff over there. Can you post you config here then? Also are you trying to read an analog or a state?

[Wayne Black]

Heres how I'm setting up my analog;

;***Analog Sensors for Nozzle pressure
;-Common Parameters
;-Sn Sensor number
;-P"pin_name" The name of the control board pin that this sensor uses. For thermistors it is the thermistor input pin name, see Pin Names. For sensors connected to the SPI bus it is the name of the output pin used as the chip select.
;-Y"sensor_type" The sensor and interface type, one of: "thermistor", "pt1000", "rtd-max31865", "thermocouple-max31855", "thermocouple-max31856", "linear-analog", "dht21", "dht22", "dhthumidity", "current-loop-pyro", "drivers", "mcu-temp" (see note below regarding "mcu-temp" support on Duet 3 Mini 5+). Duet WiFi/Ethernet with an attached DueX2 or DueX5 also support "drivers-duex". Firmware 3.2 and earlier also supports "dht11" but this support is likely to be removed in future firmware versions.
;-A"name" Sensor name (optional), displayed in the web interface
M308 S0 P"temp0" Y"linear-analog" A"Pressure_1" F0 B0 C4095
M308 S1 P"temp1" Y"linear-analog" A"Pressure_2" F0 B0 C4095

Heres how I read my analog;
M118 P1 S{sensors\u002Eanalog[1]\u002ElastReading}

Heres how I setup my switch input

;-M950: Create heater, fan, spindle or GPIO/servo pin \ https://duet3d.dozuki.com/Wiki/M950
;-Parameters:
;-Hnn Heater number
;-Fnn Fan number
;-Jnn Input pin number (RRF 3.01RC2 and later only)
;-Pnn or Snn Output/servo pin number. Servo pins are just GpOut pins with a different default PWM frequency.
;-Rnn Spindle number (RRF 3.3beta2 and later only)
;-Dn (Duet 3 MB6HC running RRF 3.4 or later only) SD slot number (the only value supported is 1)
;-C"name" Pin name(s) and optional inversion status, see Pin Names. Pin name "nil" frees up the pin. A leading '!' character inverts the input or output. A leading '^' character enables the pullup resistor1. The '^' and '!' characters may be placed in either order.
;-Qnn (optional) PWM frequency in Hz. Valid range: 0-65535, default: 500 for GpOut pins, 250 for fans and heaters
;-T Temperature sensor number, required only when creating a heater. See M308.
;-Lbbbor Laaa:bbb RPM values that are achieved at zero PWM and at maximum RPM. (optional and for spindles only - RRF 3.3beta2 and later)
;***Inputs
M950 J3 C"!io3.in" ;Drag Pin Sensor

Heres how I read my switch input

M118 P1 S{sensors\u002EgpIn[3]\u002Evalue}

[JW]

Yep, just nothing... and sometimes get "you don't have permission to do this" popups.

Config attached.

If I run this M code in DWC, it returns 0 and 1, depending on the physical switch state, so that appears to be fundamentally working having setup the input in config.

M409 K"sensors.gpIn[1].value"

And this is the homing script (I'm actually doing everything in X right now, but that's neither here nor there I don't think).

G91               ; relative positioning
if sensors.gpIn[1].value == 0
G1 H1 X-235 F500 ; move X down until the endstop is triggered
else
G1 H1 Z235 F500 ; move X up in this case
G1 H0 X10 F2000  ; move quickly
G90               ; absolute positioning

So, this works fine if I don't close the second switch, it starts spinning the motor, stops when I press the limit switch, and goes back the other way a little.

If the second switch is depressed however, when I call HomeX, it just seems to hang. DWC reports 'busy', and nothing is happening.

[JW]

Can't seem to edit messages here either? When I say it hangs and does nothing, I literally have to reset the Duet before it'll action any other command.

[Wayne Black]

So you no longer have the out of index error?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8292e505-bb6b-4e42-b44a-f205ed9bfc5cn%40googlegroups.com.

[JW]

Not anymore, no - now that I've got the second switch properly configured in config.g. I assumed (wrongly) that all inputs were essentially already active, and you could just read from them immediately.

So that makes sense why I got an out of index error, as the input I was trying to read wasn't yet configured.

[Wayne Black]

Ok good, and how are you calling the home routine? If you are jsut calling homex.g then the duet should not hang, but if you call homeall.g it will hang until your other defined axii limits are tripped.

[JW]

I'm not sure I understand your M118, is there some forum unicode encoding incompatibility going on?

Is M118 P1 S{sensors\u002EgpIn[3]\u002Evalue} meant to read as M118 P1 S{sensors.gpIn[3].Evalue}?

[Wayne Black]

I'm not sure I understand your M118, is there some forum unicode encoding incompatibility going on?

Yes, good catch. I think thats from when I had had gcode compression setting in Openpnp, the regex wasnt parsing correctly

[JW]

When you say you're using M118, do you mean in the homing script?

What firmware are you running?

If I run send M118 P1 S{sensors.gpIn[1].value} via DWC, nothing happens, if I run it in the homing script, it simply complains about M118 being an 'unknown value'.

[JW]

Well this is embarrassing if you look carefully again at my homing script, in the else case, it tries to move Z, not X!

Updating to the below, works perfectly!

G91               ; relative positioning
if sensors.gpIn[1].value == 0

G1 H1 X-235 F500 ; move Z down until the endstop is triggered
else
G1 H1 X235 F500 ; move Z up in this case

G1 H0 X10 F2000  ; move quickly
G90               ; absolute positioning

But, I'm still keen to understand and learn what you were trying to explain with M118?

This also gives me the confidence I need now to progress the head design using the potentiometer. I'm going to go about to by feeding the signal into 2 comparator circuits; 1 to report high/low to tell Duet which way to home using the above script, and another into a windowed comparator circuit so when the angular feedback signal is say 2.47 - 2.53V, go high to indicate we're at the middle position.

Despite my stumbles, overall I'm very impressed with the Duet/RFF platform!

[JW]

Ah, and need to remove the move post endstop triggering.

So it's an simple as:

G91               ; relative positioning
if sensors.gpIn[1].value == 0
G1 H1 X-235 F500 ; move Z down until the endstop is triggered
else
G1 H1 X235 F500 ; move Z up in this case

G90               ; absolute positioning

And when Duet stops the motion, we're homed!

[Wayne Black]

Cool! Look forward to what you come up with. It really is a shame about the Duet forum. If you keep having issues, I'd reach out to a moderator. They are super helpful over there. Here as well, but duet related stuff is best directed to them.

Lastly, Mark is huge help, resource and contributor for the group. Carefully consider his recommendations.

[JW]

Yep, that's the next step - getting those soft limits in as Mark suggests, and my heads can move down to the point that the Juki nozzles would bottom out. I see Mark's name everywhere!

Will try and sort the Duet forum issue...

Thanks for both of your help getting to this point, happy to have it running already.

[JW]

That's odd, just posted this message but it shows as deleted.

Quick update on this, head design is done. It uses a 0.4mm thick angular membrane potentiometer underneath the Z spur gear hub, which feeds it's signal to a small PCB on the head, which does a number of things such as vacuum sensing, valve control etc.

The pot's signal feeds a comparator that switches low/high at 2.5V, or Z nozzles balanced, so we know which way to start homing, and also a windowed comparator circuit that goes high at balance +/- 0.4mm.

The mounting block of the head that attaches to the ballnut housing also acts as a vacuum distribution manifold, and the underside mounting pressure sensors on the head PCB break into this manifold to sense vacuum with no dedicate vacuum sense hoses etc.

For the eagle eyed among you, there's 4 valves but only 2 nozzles... I just had these 4 valves and a 4 valve manifold left over from something else.

[JW]

[JW]

Just received PCBs today, so will get those assembled tomorrow, but the membrane pot output works exactly as expected, just feeding into a 'scope.

[Wayne Black]

Interesting design.

Are you plumbing the vacuum sensors directly through the bearing block?

The orientation of the nozzle rotation motors are inverted? Wont the driver cables have to double back up along the vacuum tubes anyway? 

On Fri, May 3, 2024 at 4:35 PM JW <julian...@gmail.com> wrote:

Just received PCBs today, so will get those assembled tomorrow, but the membrane pot output works exactly as expected, just feeding into a 'scope.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/0c7b6758-a86c-4f64-93f3-744c6204adban%40googlegroups.com.

[JW]

Yes, the 2 hose fittings either side are just in/out, i.e. they're connected directly together, but then connected to that same drilling is the pressure sensor

Yes, the motors are technically 'upside down' requiring the cable to turn 180 degrees, but having tried both orientations, this is actually nicer as I can have a tidy cable clip on the motor body that stops any movement at the cable/connector junction. Putting them 'the right way up', the best you can do is secure the cable a few inches up on the vacuum hose.

[Wayne Black]

Cool :)

My first engineering job was for an instrumentation company that specialized in gas measurement. They specialized/patented intricate gas passage blocks for intrinsic safety. Youre design reminds me of it :)

Looking forward to seeing your head in action. Is that a one off/custom spur gear you made or can you order them? I did a spur gear design once and the rack and pinion parts were super hard to find a the time. Im finding using belts w 16mm timing pulley can make for a pretty compact design

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4458add2-410e-4634-afc0-6a1ff84a312en%40googlegroups.com.

[JW]

Ah, then you know all too well then that every joint, and especially moving joints, are a leak risk!

The spur and rack are both KHK parts (https://khkgears.net/pdf/bss.pdf), available in a few days from their local distributor here, then just modified for this application (removal of the hub, and cutting down length of the rack + adding mounting holes etc). If I were building many heads, I'd have just have the gears and racks cut specially, but for a 1 off it just made sense to buy stuck and modify.

The head is up and running, but haven't got the cabling tidy enough for me to want to show it in action quite yet.

[JW]

This shows the manifold a little more clearly:

You can just make out the M5 blanking grub screws with red thread sealant, sealing off the drill entry of the shared galleries.