C-axis endstop / levelling ?

[Peter Van Aken]

Hi,

I'm in the process of building a PnP and have a question about the c-axis (or head). 

What's normally used to level the height ? (switch, probe, nothing,....)  The PCB / feeders are not per definition at the same height or should they ?

As first test I'll base myself on a Smoothieboard with DRV8825 stepper drivers. (no sensorless homing)

Cheers,

Peter

[Jason von Nieda]

Hi Peter,

OpenPnP allows you to set the height for each individual thing (feeder, PCB, etc). There is rudimentary z-probe support, as well, but this is an active area of development and it's still pretty new and basic. In general, if you can put the boards and feeders at the same height that will make things easier, but OpenPnP is designed to work without it.

Jason

--
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/dd7010c7-4dcf-4aee-a6d5-58907ad6e16f%40googlegroups.com.

[Peter Van Aken]

Thx Jason. 

Op dinsdag 30 juli 2019 17:29:38 UTC+2 schreef Jason von Nieda:

Hi Peter,

OpenPnP allows you to set the height for each individual thing (feeder, PCB, etc). There is rudimentary z-probe support, as well, but this is an active area of development and it's still pretty new and basic. In general, if you can put the boards and feeders at the same height that will make things easier, but OpenPnP is designed to work without it.

Jason

On Tue, Jul 30, 2019 at 10:24 AM Peter Van Aken <pier...@gmail.com> wrote:

Hi,

I'm in the process of building a PnP and have a question about the c-axis (or head). 

What's normally used to level the height ? (switch, probe, nothing,....)  The PCB / feeders are not per definition at the same height or should they ?

As first test I'll base myself on a Smoothieboard with DRV8825 stepper drivers. (no sensorless homing)

Cheers,

Peter

--
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 ope...@googlegroups.com.

[Mike Menci]

Hello Jason

Is the smoothie branch updated to the latest edge version?

Mike

On Tuesday, 30 July 2019 17:29:38 UTC+2, Jason von Nieda wrote:

Hi Peter,

OpenPnP allows you to set the height for each individual thing (feeder, PCB, etc). There is rudimentary z-probe support, as well, but this is an active area of development and it's still pretty new and basic. In general, if you can put the boards and feeders at the same height that will make things easier, but OpenPnP is designed to work without it.

Jason

On Tue, Jul 30, 2019 at 10:24 AM Peter Van Aken <pier...@gmail.com> wrote:

Hi,

I'm in the process of building a PnP and have a question about the c-axis (or head). 

What's normally used to level the height ? (switch, probe, nothing,....)  The PCB / feeders are not per definition at the same height or should they ?

As first test I'll base myself on a Smoothieboard with DRV8825 stepper drivers. (no sensorless homing)

Cheers,

Peter

--
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 ope...@googlegroups.com.

[Mike Menci]

Is this -https://github.com/openpnp/Smoothieware/commit/5de985c2a51398c59202e47eb462e57847197f84

included - or please let me have a link to latest included smoothieware Z homing
Thanks in advance
Mike

[Jason von Nieda]

The OpenPnP branch includes that change, to support the Peter style head, but the branch has not been updated to Smoothie's edge for quite some time.

Jason

--
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/ab409f1b-e4b1-452f-ae38-659ae25f9dbd%40googlegroups.com.

[Mike Menci]

Thank you Jason for your reply but Im still lost to find the branch with latest double head Z homing included. 

Please can you share a link ?

Mike

On Wednesday, 21 August 2019 16:18:51 UTC+2, Jason von Nieda wrote:

The OpenPnP branch includes that change, to support the Peter style head, but the branch has not been updated to Smoothie's edge for quite some time.

Jason

On Wed, Aug 21, 2019 at 4:55 AM Mike Menci <mike...@gmail.com> wrote:

Is this -https://github.com/openpnp/Smoothieware/commit/5de985c2a51398c59202e47eb462e57847197f84

included - or please let me have a link to latest included smoothieware Z homing
Thanks in advance
Mike

--
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 ope...@googlegroups.com.

[Jason von Nieda]

Hi Mike,

The code is at https://github.com/openpnp/Smoothieware (the edge branch, which is the default) and the pre-built firmware.bin is at https://github.com/openpnp/Smoothieware/blob/edge/FirmwareBin/firmware.bin

Jason

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/35941c77-4fdb-479f-a189-dfedd0b7b2a9%40googlegroups.com.

[Mike Menci]

This is the latest ? 3 years old and Smoothie has 2 months old update, 

Is there someone out there who has latest merge bin and can share it ? 

 Mike

On Wednesday, 21 August 2019 18:59:50 UTC+2, Jason von Nieda wrote:

Hi Mike,

The code is at https://github.com/openpnp/Smoothieware (the edge branch, which is the default) and the pre-built firmware.bin is at https://github.com/openpnp/Smoothieware/blob/edge/FirmwareBin/firmware.bin

Jason

On Wed, Aug 21, 2019 at 11:57 AM Mike Menci <mike...@gmail.com> wrote:

Thank you Jason for your reply but Im still lost to find the branch with latest double head Z homing included. 

Please can you share a link ?

Mike

On Wednesday, 21 August 2019 16:18:51 UTC+2, Jason von Nieda wrote:

The OpenPnP branch includes that change, to support the Peter style head, but the branch has not been updated to Smoothie's edge for quite some time.

Jason

On Wed, Aug 21, 2019 at 4:55 AM Mike Menci <mike...@gmail.com> wrote:

Is this -https://github.com/openpnp/Smoothieware/commit/5de985c2a51398c59202e47eb462e57847197f84

included - or please let me have a link to latest included smoothieware Z homing
Thanks in advance
Mike

--
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 ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ab409f1b-e4b1-452f-ae38-659ae25f9dbd%40googlegroups.com.

--
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 ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/35941c77-4fdb-479f-a189-dfedd0b7b2a9%40googlegroups.com.

[ma...@makr.zone]

Hi Mike

(answering this PM below in the group)

I have looked at the mid-Z homing Jason did and unfortunately the underlying code has changed completely, so we can't merge this.

I would have to re-think and then re-do this and so far I haven't found the time and energy. Also judging from past experience trying to contribute to Smoothieware the chances are high that the change would - again - not be accepted, which sucks. Plus I only have a single nozzle machine, so I wouldn't even be able to test it, which in this case is essential.

I was hoping you could do it with Z-probing instead. We discussed it in this thread:

https://groups.google.com/d/msg/openpnp/LIMVWRXhmIc/kKQ23P49BQAJ

G38.4 Z-40     ; get out of probe signal by max. 40mm

G38.2 Z+40     ; probe Z by max 40mm

G92 Z0         ; set this as Z home

G28 X0 Y0      ; home X and Y

Just adjust the 40mm to your machine maximum stroke.I haven't tested this though it's just out of thin air.

If you want to give it a try again, use the latest Smoothieware:

https://github.com/Smoothieware/Smoothieware/blob/edge/FirmwareBin/firmware-latest.bin

_Mark

Am 21.08.2019 um 19:44 schrieb M. Mencinger:
> Hello Mark,
> Thanks for your support & contribution to Open PNP
> I was wondering if you are inline with latest Smoothiware Bin and if you have merged two head Bin to share ?
> https://groups.google.com/forum/#!topic/openpnp/2zbqS_uHGAg 
>
> Thanks
>
> Mike
>
>  SAVE THE NATURE - SAVE PAPER - THINK BEFORE YOU PRINT!  "

[ma...@makr.zone]

To be a bit more specific:

• Use a new firmware (the old one does not have Z probing)
• Disable the Z endstop (nc)
• Setup Z probing as described here: http://smoothieware.org/zprobe#configuration-options
• Try the homing GCode given above

_Mark

[Mike Menci]

Hello Mark
Thanks for joining in this thread

I am asking about Z homing in a way;
Rack and Pinion Head is Homing;
The Z axis has a home switch that is triggered for half the length of the axis. To home it we need to first check if the switch is triggered, and if it is we need to back off until it's no longer triggered. Then we can perform a normal homing operation.

Mark /Your reply is related to “z hight sensing” and not Z homing?
Am I Correct ?
Mike

[ma...@makr.zone]

Hi Mike

No my proposal is for Z homing with a "Peter's Head" or similar (any "see-saw" type shared axis head).

I am proposing to (ab)use the GCode probing commands that are normally used in a 3D printer for bed levelling.

These switches can be used for three purposes:

1. endstop for homing: Unfortunately Smoothieware assumes that if the switch is engaged, the machine is outside its working range. But that is obviously not the case with a Peter's head.
   
2. limit switch: Even worse, the machine will be halted when engaged outside the homing cycle.
3. Z-probe: To my knowledge Smoothieware makes no assumptions between the switch state and the working area. Specifically the probe command can be given a "search range". You can both probe into or out-of the switch.
   

So without changing the firmware, only the 3rd way remains.

Note that these probing commands are also used in various CNC applications to probe for a work piece or even to digitize 3D surfaces. So it is not so outlandish to probe for the mid-point of a "Peter's Head".

_Mark

[Mike Menci]

Hello Mark,
Ok I got your point! I will try this out this evening and let you know!

Mike

[Juan-Antonio Søren E. Pedersen]

This is good to know. I was about to look at a solution for the z homing. Thanks for bringing this up. From looking at cnc machines I have found the cnc touch plate probe to be mandatory for the carving tool function I’m working on for the beefy pnp. Could that kind of probe work? 

I do have a 4mm inductive sensor probe lying around. 

I guess, when probing for Z, the machine know where to make the measurements ? Right. Could this be several spots on the build plate? 

--
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/b9fdca84-db37-4aa8-9fb9-600776415094%40googlegroups.com.

[ma...@makr.zone]

Hi Morpheus

I think you and Mike are talking about two different things.

• Mike is talking about homing the Z axis in a dual nozzle machine. The homing switch is engaged when the two heads are at equal height, i.e. in the middle of the physical Z axis range. You only need one shared Z axis and one shared homing switch for the two "virtual" Z axes of the two nozzles.
  http://www.betztechnik.ca/store/p34/Pick_and_Place_head_-_dual_nozzle_-_OpenPnP_compatible.html
  
• You are talking about probing the machine build plate, where you would need a separate probe per nozzle, i.e. two probes/switches for a dual nozzle machine (but you can share the pin and configuration in Smoothie). That's also a sensible way to home Z axes but obviously it is not the same thing.
  

And unfortunately I know virtually nothing about inductive sensors. Though I keep reading that they are overrated as compared to good mechanical precision switches.

_Mark

[Juan-Antonio Søren E. Pedersen]

Yes, I was talking about the same thing. I was thinking it could be possible to mount the inductive probe on one of the nozzle mounts and have a “probe tower” at a given location. Would this be folly ? How often to the machine z home?

--
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/2bccee7c-edcd-49f7-ae9b-c8d86f2095e3%40googlegroups.com.

[Juan-Antonio Søren E. Pedersen]

This is a good semi scientific test of different probes. He concludes that inductive is ok. 

https://youtu.be/il9bNWn66BY

[SMdude]

One thing to consider is that the machine might be homing at any random location.

When it starts to home, Z has to be first.

We want Z to do nothing other than retract back to its homing position, going down to probe the partially placed board that is underneath it isn't exactly desirable behavior.

It would be nice if a more current smoothie version were modified to home correctly with a dual nozzle setup.

As far as it being merged into the smoothieware branch, don't worry about it. The 3d printer guys don't do Z homing like we do. If it were modified, submit it to Jason and he can put it with the other version that has been modified for openpnp.

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

[Juan-Antonio Søren E. Pedersen]

From 3d printing on a delta machine I know it’s nice to be able to manually adjust end-stops. 

I see your point regarding homing the nozzles first. 

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/fa764f5e-882b-43bd-b151-978a33990456%40googlegroups.com.

[Juan-Antonio Søren E. Pedersen]

This pnp machine homes in on x and y before homing the dual head.

https://youtu.be/61YRYqdPd7U

I’m sorry for my newbi questions, but how many times does it meet to home the nozzles? Wouldn’t one time before a job suffice?

[ma...@makr.zone]

It would be nice if a more current smoothie version were modified to home correctly with a dual nozzle setup.

Yes but see why that is not so easy here:

https://groups.google.com/d/msg/openpnp/2zbqS_uHGAg/vqhzFyFEDwAJ

_Mark

[Morpheus]

I’ll give it a go with the inductive probe. I don’t mind overseeing the machine doing its initial homing. I don’t plan on doing remote assembly just yet. Mark, thanks for the suggestion.

[Mike Menci]

Hello Mark

enclosed config file - I use Zmax - 1.29 as probe

With Pronterface I get no movement of "Z" :

ok V:inf /0.0 @0 W:inf /0.0 @0
Printer is now online.
ok V:inf /0.0 @0 W:inf /0.0 @0
ok V:659.5 /0.0 @0 W:659.4 /0.0 @0
>>> G38.4 Z-15
SENDING:G38.4 Z-15
>>> G38.4 Z-15
SENDING:G38.4 Z-15
ok V:659.6 /0.0 @0 W:659.5 /0.0 @0
>>> G38.2 Z+15
SENDING:G38.2 Z+15
ok V:659.8 /0.0 @0 W:659.8 /0.0 @0
>>> G28 Z0
SENDING:G28 Z0
ok V:659.6 /0.0 @0 W:659.8 /0.0 @0
>>> G28 X0 Y0
SENDING:G28 X0 Y0
ok V:659.8 /0.0 @0 W:659.8 /0.0 @0
>>> G28 X0 Y0 Z0
SENDING:G28 X0 Y0 Z0
ok V:659.8 /0.0 @0 W:659.6 /0.0 @0
>>> G38.4 Z-40
SENDING:G38.4 Z-40

With Open PnP as well no movement into homing - Z is still standing

All moves with jog are OK.

see enclosure

[Mike Menci]

Aand this is the home command

[Mike Menci]

I have probe disabled - I need it enabled - I test again....

[Mike Menci]

[SMdude]

For anyone interested, I think the homing code that needs to be modified starts at line 501

https://github.com/Smoothieware/Smoothieware/blob/de35392f66aac45c7e1c1f9b5889936dd0b02ee5/src/modules/tools/endstops/Endstops.cpp#L501

Something would need to be added that executes if the Z endstop is triggered to retract until not triggered during Z homing.

[ma...@makr.zone]

Hi SMdude

if it were that cleanly separated I would have done it a long time ago. :-)

The code you're referring to is the retraction AFTER the homing.

What we need is retraction BEFORE the homing.

Unfortunately the order of axes in homing can be arbitrary and different arm solutions (Delta, Cartesian...) as well as Core-XY machines have different homing methods (i.e. you are homing physical "actuators" rather than logical "axes") all of which leads to very complex code here:

https://github.com/Smoothieware/Smoothieware/blob/de35392f66aac45c7e1c1f9b5889936dd0b02ee5/src/modules/tools/endstops/Endstops.cpp#L768

I'm sure it can be done, but not so easily.

_Mark

[SMdude]

Oh, I see! That is really convoluted! This is the problem with trying to support every possible scenario.

Wonder if it could be stripped back to just support cartesian machines? After all, 98% of the openpnp builds are a cartesian machines. I would not worry about the changes being able to merge back to smootieware.

In reality, we don't need to keep up with edge, but it would be nice to have something later than what we currently have modified for openpnp. Apart from the soft limits, is there anything else that is a must have in the later firmwares? I haven't been keeping track.

[ma...@makr.zone]

Hi Mick

if Mike Menci fails using Z-probe commands for homing, I will reconsider giving it a try.

See here:
https://groups.google.com/d/msg/openpnp/2zbqS_uHGAg/vqhzFyFEDwAJ
https://groups.google.com/d/msg/openpnp/2zbqS_uHGAg/06HQIOd7DwAJ

This should be tried first, IMHO.

_Mark

[Mike Menci]

Hello Mark
See enclosure above !
G38.4 is not supported
Mike

[Mike Menci]

Here

[ma...@makr.zone]

Oh no! Yes you're right!

http://smoothieware.org/supported-g-codes

http://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G38-probe

This is a pitty. It would actually be more standards compliant (i.e. usable on other controllers) to use these probing codes than hacking the homing system.

Sorry to have wasted your time.

_Mark

[ma...@makr.zone]

OK.

Are you guys ready to help with testing? Because I don't have a dual-nozzle machine and I also don't have time to rig something up.

Here's a branch based on the latest edge:

https://github.com/markmaker/Smoothieware/tree/feature/endstop-release-first

Changes:

https://github.com/markmaker/Smoothieware/commit/4f64e124d11eef51e0e0acfa45c8a641146d9e59

Though I'm a mindful coder, this is completely untested. Only do this if you know how to flash and restore a Smoothie. This code is only enacted in the homing cycle so you should always be able to boot and reflash it. But no guarantees given.

You need to setup your config as follows:

1. Flash this firmware (or build yourself from the branch given above):
   https://makr.zone/firmware_edge_endstop_release.bin
2. For your config you must use the modern 6-axis endstop syntax, not the old "greek" one!
   http://smoothieware.org/6axis
   
3. Change the config to include the following line (different endstop also possible of course):
   endstop.minz.release_first      true     # first move away from endstop until released
4. Reset to reload.
   

Hope this helps.

_Mark

[Mike Menci]

Hello Mark, 

Thank you so much for making this possible for us, No you are not wasting my time :-), I am taking your time! 

Z works 

general problem with x, y is retract does not work .. 

Up to now tested only with Pronterface : 

SENDING:M119 (state of limits) 

X_min:0 Y_min:0 Z_max:1 pins- (X)P1.24:0 (Y)P1.26:0 (Z)P1.29:1

ok V:659.8 /0.0 @0 W:659.6 /0.0 @0

ok V:659.8 /0.0 @0 W:659.8 /0.0 @0

>>> M119

SENDING:M119 after homing

X_min:1 Y_min:1 Z_max:1 pins- (X)P1.24:1 (Y)P1.26:1 (Z)P1.29:1

ok V:659.9 /0.0 @0 W:659.8 /0.0 @0

Enclosed my Config File for your review - you might find an error ?

Mike

[Mike Menci]

Mark - it is working fine on Open PnP - including retracting from Xmin, Y min, Z is Ok - but I must finish here next to PnP for tonight... 

Thank you so much. 

I hope other guys will test it as well.... 

Good night!

Mike

[SMdude]

Hi Mark,

Thanks for your effort on this!

I will test it out next time I do a run(probably a week or 2)

[ma...@makr.zone]

Thanks for testing this Mike.

Your text is a bit short, I'm not sure I get a complete picture of what you have tested exactly and if everything was fine.

Specifically with Z steppers switched off, the nozzles should be manually pulled into various starting positions (from fully extended left nozzle to close around the switching point to fully extended right nozzle in several steps). From each starting position Z should be homed to test whether it works as expected. 

Ideally you could make a little movie of the nozzle first moving to release the endstop switch and only then doing the actual homing cycle.

If this is successful and ideally with a little movie to demonstrate, I will make a pull request. Who knows maybe they have a heart for you dual-headers :-)

https://www.artstation.com/artwork/WBVz2
https://en.wikipedia.org/wiki/Orthrus

_Mark

[Mike Menci]

Hi Mark 

See your mail - Video links 

My C1 and C2 stepers heat up ? might be something wrong in config. file - enclosed

- Pronterface ; no retract happens from X and Y when homing 

- Open PnP - retract is there! 

Mike

[Mike Menci]

Video link folder : https://drive.google.com/drive/folders/1QHNaH3bAD0yWaS3pPgFbUD-DdSQerFfF
Mike

[Mike Menci]

On You Tube; https://youtu.be/clSgZcXOxtI

[Mike Menci]

I read in Smoothie;
Do not use Notepad++ to edit the configuration file, it thinks it's smarter than everybody and modifies the file in invisible ways that can make it unreadable or confusing to Smoothie.

Looking for a good simple text editor that runs under Windows and will edit Smoothie config files with no problems? Try https://wiki.gnome.org/Apps/Gedit

In more detail : Notepad++ will change the encoding to UTF8 by default but you can force it to use ANSI and it will be fine.

ANSI and UTF8 are equivalent for a subset of characters but sometimes quotes and such can be replaced with Unicode variants.

I did it - config. with Notepad ++, I will re-do it as written above!
And test again
Mike

[SMdude]

Hi Mike,

For your hot C axis motors, you might need to turn your current down for them.

[Mike Menci]

I did already from 0.45 to 0.3 still they heat up very fast 3min they are hot - you can hardly touch them so hot!

[ma...@makr.zone]

> Videos

Very nice, Mike, thanks a lot.

I'll make a small GIF out of the telltale moment in that and include it in the PR.

> - Pronterface ; no retract happens from X and Y when homing

That's strange.

• When you say "retract" do you mean the retract, AFTER the actual homing, as configered?
  

  endstop.minx.retract                         5                # bounce off endstop in mm

• What is different between the two homing sequences (Gcode)?
  

> My C1 and C2 stepers heat up ?

As those axes don't have endstops configured, I cannot imaging that is has something to do with the change. Must be some other side effect of the new firmware. Are you sure it was different with the old firmware?

_Mark

[ma...@makr.zone]

Hi

I made the Pull Request, documented with Mike Menci's video (thanks for that!).

https://github.com/Smoothieware/Smoothieware/pull/1423

To increase the chances of it being followed through and accepted, dual-nozzle Smoothie users are hereby encouraged to help with more testing and/or to weigh in for the adoption of the PR.

Testing guidance:

https://groups.google.com/d/msg/openpnp/2zbqS_uHGAg/76zeHIfXDwAJ

Why the effort?

A similar change was made by Jason:

https://groups.google.com/d/msg/openpnp/QpSp-ONilcM/LIX1WXWJBgAJ

As the underlying code was rewritten soon after that, users are now stuck with Jason's July 2016 version and can't benefit from any of Smoothieware's more recent improvements. This PR aims to change that.

Thanks,

_Mark

[Mike Menci]

Thanks Mark!
Mike

[Marek T.]

I'm using only Notepad++ for Smoothie and never had any problems.
In case of Smoothie "Save as Ansii" does the job. But even if I don't force Ansii but just open the config and do regular Save - it's also working (maybe it recognizes ascii while opening and then use same saving, I don't know, didn't try to investigate it).

[Mike Menci]

Hello Mark, 

after bothering with new confif file - latest -working for me enclosed 

Here is what I figured out: 

> - Pronterface ; no retract happens from X and Y when homing  

If I remember correct in Proterface retracting did happen IF YOU HIT HOME ANY OF AXIS OR ALL AXIS !?    

Can someone check this ?? with V1 Open PnP

endstop.minx.retract                         5                # bounce off endstop in mm

endstop.miny.retract                         15               # bounce off endstop in mm
endstop.maxz.retract                         6                # 2 bounce off endstop in mm

This is not happening neater in Pronteface neater Open PnP - it happens only after I set Visual homing where the units for finding fiducial point are set for X and Y in machine file. 

endstops_enable                         false            # The end-stop module is enabled by default and can be disabled here IF set to True Homing is not working at all  !!     why?
include abc-endstop.config           true            #
endstop.maxz.release_first           true            # first move away from........

That's strange. 

• When you say "retract" do you mean the retract, AFTER the actual homing, as configered?
  

  endstop.minx.retract                         5                # bounce off endstop in mm

• What is different between the two homing sequences (Gcode)? - see above!

> My C1 and C2 stepers heat up ?   This is solved -my Config was wrong!

 

I might have errors in enclosed conf file ? anyone please comment if any - or try this config on your machine ..... and report here. 

Mike

[Mike Menci]

Here the video ; https://youtu.be/R4ZGYkgMLdw

[ma...@makr.zone]

Hi Mike and everybody interested in testing

I found a bug. It might explain the problems Mike described. When the axis is not in the range where the switch is already engaged, i.e. when the new "release first" move is not needed, homing won't work reliably.

I uploaded a new firmware version with a fix to the same URL here:

https://makr.zone/firmware_edge_endstop_release.bin

Mike, if possible, please test systematically, step-wise, to diagnose such issues deterministically:

• with Z steppers switched off, the nozzles should be manually pulled into various starting positions (from fully extended left nozzle to close around the switching point to fully extended right nozzle in several steps). From each starting position Z should be homed to test whether it works as expected. 

Details of the bugfix, see here:

https://github.com/Smoothieware/Smoothieware/pull/1423/commits/32a9f9b3f74df40aaac7cc92122325ea7b97746f

This also includes all the stylistic changes requested by wolfmanjm. See the discussion here:

https://github.com/Smoothieware/Smoothieware/pull/1423 

(up to https://github.com/Smoothieware/Smoothieware/pull/1423/commits/cba914b833c6360c57eb85dc608355c80c0e7e95)

_Mark

[ma...@makr.zone]

On Sunday, August 25, 2019 at 8:54:27 PM UTC+2, Mike Menci wrote:

Here the video ; https://youtu.be/R4ZGYkgMLdw

Hi Mike

what you show in the video is normal. OpenPNP does two homings, a mechanical and a visual. After each homing the same home coordinates are set. If you have your visual homing fiducial at an offset, this will actually create an offset between the mechanical and visual home.

Jason has actually described this behaviour as a possible bug. 

https://groups.google.com/d/msg/openpnp/aaVr5LwxM6Q/v-aHudRnBgAJ

More detail:

https://groups.google.com/d/msg/openpnp/aaVr5LwxM6Q/iFRsPXFwBgAJ

To change that, add a move close to the fiducial to your HOME_COMMAND.

Still: the bug I described should also be fixed, so please load the new firmware.

_Mark

[Mike Menci]

Hi Mark, 

Tested latest version from minutes ago(still hot :-).  

Yes it is working reliably. 

You are right homing is as it should be - see here my questions to Arthur - https://groups.google.com/forum/#!topic/smoothieware-support/jekYVmo1mL4 and this part of his reply: 

"First time, homing Z, it does the full Z homing sequence, that is seek home in Z then move to origin in Z

Second time, it does the full XYZ homing sequence, that is seek home in Z, then XY, then move to origin in XYZ - This is how it is supposed to work."

Will do more testing tomorrow and come beck to you. 

Good night for tonight and big thank you!

Mike

[Morpheus]

Hi

I’ve tested the inductive endstop/probe for homing z.

Made a short movie documenting the machine doing homing procedure.

https://vimeo.com/357219153

I have set z min to negative value that equals the z retract after homing. Gamma must have limit enabled for it to move the retract distance.

Does the machine often home z? I do not have experience working with openPnP 2.0 yet. Just getting my heat wrapped around it.

@Mark. My steppers are humming a lot with the BSD2660. How do I set the hold current. Could you share the confit you mentioned?

[ma...@makr.zone]

> Made a short movie documenting the machine doing homing procedure.

Nice.

> I have set z min to negative value that equals the z retract after homing.

You mean gamma_min? Does this even work mixed-in with the new endstop syntax?

Assuming you are talking about the PR I made you should only use the new syntax i.e. "homing_position":

endstop.minz.homing_position                 -5               # the cartesian coordinate this is set to when it homes
endstop.minz.retract                         5                # bounce off endstop in mm
endstop.minx.release_first                   true             # first move away from endstop until released

http://smoothieware.org/6axis

> Gamma must have limit enabled for it to move the retract distance.

I don't understand. Probably related...

> Does the machine often home z?

Usually once per usage. But you should not do shortcuts there.

Make sure to run tests as I described:

https://groups.google.com/d/msg/openpnp/2zbqS_uHGAg/XMSzJtt_EAAJ

> @Mark. My steppers are humming a lot with the BSD2660. How do I set the hold current. Could you share the confit you mentioned?

You need two parts:

1. the config.txt > https://makr.zone/config.txt
2. a boot GCode script tuning the motors > https://makr.zone/on_boot.gcode

WARNING: use these files only as guidance, as everything will be different with your machine (axes, pins, endstops etc.)!

_Mark

[Juan-Antonio Søren E. Pedersen]

Thx 

Have too read up on that.

Yes, gamma_min.

The retract function only sets in if gamma  limit is set to true. This function is called to avoid the end stop being pressed after home, which would halt everything.

I don’t know the former or the new syntax.    

--
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/251706f0-bef8-bc22-62e5-273f3692bdbc%40makr.zone.

[Juan-Antonio Søren E. Pedersen]

Mark! Awesome script! I 

There is one thing though. I know its overkill to run a nema8 on TMC2660, but thats what i have. right now. Its getting quite warm when holding still, motors on.

Im expecting some DRV8825 stepsticks anyday now, since i killed one of the TMC2660, so i want make a big fuss about it. But do you think they can run the nema8´s?

[ma...@makr.zone]

> I know its overkill to run a nema8 on TMC2660

Yeah but you can always dial down the current. For instance I run my rotation with just 500mA MAX using this command:

M906 A500

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2B7Q0cNkWQZBrc8d%2B%3DGCyY7c6440VivNbuSNGDzj3cZaKh7QSQ%40mail.gmail.com.

[Morpheus]

I have tested the bin file you linked to, and there is no conflict with the way i have set homing up.

mandag den 2. september 2019 kl. 03.14.40 UTC+2 skrev ma...@makr.zone:

> I know its overkill to run a nema8 on TMC2660

Yeah but you can always dial down the current. For instance I run my rotation with just 500mA MAX using this command:

M906 A500

_Mark

Am 02.09.2019 um 02:05 schrieb Juan-Antonio Søren E. Pedersen:

Mark! Awesome script! I 

There is one thing though. I know its overkill to run a nema8 on TMC2660, but thats what i have. right now. Its getting quite warm when holding still, motors on.

Im expecting some DRV8825 stepsticks anyday now, since i killed one of the TMC2660, so i want make a big fuss about it. But do you think they can run the nema8´s?

Den søn. 1. sep. 2019 kl. 23.54 skrev Juan-Antonio Søren E. Pedersen <greenh...@gmail.com>:

Thx 

Have too read up on that.

Yes, gamma_min.

The retract function only sets in if gamma  limit is set to true. This function is called to avoid the end stop being pressed after home, which would halt everything.

I don’t know the former or the new syntax.    

To unsubscribe from this group and stop receiving emails from it, send an email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/251706f0-bef8-bc22-62e5-273f3692bdbc%40makr.zone.

--
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 ope...@googlegroups.com.

[ma...@makr.zone]

Thanks!

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/e7e148aa-26eb-4f5e-810d-976815a774db%40googlegroups.com.

[ozzy_sv]

Hi guys

I installed this firmware and my nozzles stopped spinning.

Since in this firmware instead of the T0 T1 E commands   already used the names of the axes A and B are, I changed the following:

in gcode driver -> first nozle - > MOVE_TO_COMMAND insert next

G0 {BacklashOffsetX:X%.4f} {BacklashOffsetY:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{FeedRate:%.0f}
G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:A%.4f} F{BacklashFeedRate:%.0f}

in gcode driver -> second nozle - > MOVE_TO_COMMAND insert next

G0 {BacklashOffsetX:X%.4f} {BacklashOffsetY:Y%.4f} {Z:Z%.4f} {Rotation:B%.4f} F{FeedRate:%.0f}
G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:B%.4f} F{BacklashFeedRate:%.0f}

After this, the nozzles began to rotate again.

Now I do not know what to do with the following items, tell me

in gcode driver -> default ->MOVE_TO_COMMAND 

G0 {BacklashOffsetX:X%.4f} {BacklashOffsetY:Y%.4f} {Z:Z%.4f} {Rotation:E%.4f} F{FeedRate:%.0f}
G1 {X:X%.4f} {Y:Y%.4f} {Z:Z%.4f} {Rotation:E%.4f} F{BacklashFeedRate:%.0f}

in machine.xml what to do with this lines , in the properties of axes c1 and c2, leave or delete?

               

<pre-move-command><![CDATA[T0]]></pre-move-command>

Or is there another way to restore nozzle rotation ??

thanks for answers

[ma...@makr.zone]

Hi ozzy

I'm afraid I don't understand?

>After this, the nozzles began to rotate again.

vs.

> Or is there another way to restore nozzle rotation ??

Does it work, or doesn't it work?

The pre-move you can delete.

In "default" you can delete the Rotation/E axis.

Note this will be much easier in the future ;-) There will be a field for the Axis Letter:

And then you can use it in the Gcode command with the {RotationL} variable. You only need the "default" then.

_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/2e3d0934-152e-4e6c-b549-7fc7de568d65%40googlegroups.com.

[ozzy_sv]

Hi 

I'm afraid I don't understand?

Yes, my changes work.

I asked because I'm not sure I'm doing it right. but still it works

The pre-move you can delete.
In "default" you can delete the Rotation/E axis.

Ок,  I understood. many thanks.