PCBScriber support

[mattgilbertnet]

As requested, I made a branch to add support for a PCBScriber (described here). It's the "pcbscriber" branch.

I shifted most of the burden to the g-code generator, so the changes to Teacup are minimal.

Besides two new config files, "board.pcbscriber.h" and "printer.pcbscriber.h", the only other change is to the home() command in home.c. The Z axis is inverted, and "home" is when the scriber is lifted. It needs to be lifted first, before homing the x and y axes, is all.

The configuration was almost completely accomplished with the config tool, with a couple of exceptions:

• The drill is controlled the way a heater is, but without PWM and using a digital pin. It seems that the config tool only allows pin AIO2 to be selected for a heater. (Is this by design?)

• I've added a flag variable, PCBSCRIBER, to printer.pcbscriber.h. If it's defined, the firmware knows to handle homing differently.

[Wurstnase]

You can add additional //#define HEATER_PIN DIOx into your board.xx.h for more pins. This will configtool parse and you can select them.

For homing you could add a new DEFINE_HOME into the printer.xxx.h. Something like DEFINE_HOMING(x, y, z) or in a different order. In home.c use this DEFINE like in analog-arm_lpc11xx.c for example.

#undef DEFINE_HOMING
#define DEFINE_HOMING(first, second, third) \
  home_ ## first ##_negative();
  home_## first ##_positive();
.
.
#undef DEFINE_HOMING

With this, the user can define it's own order. Maybe someone want to home XZY or ZXY or whatelse.

[mattgilbertnet]

Thanks for the tip re: HEATER_PIN. I happen to be using DIO16, but it's pretty arbitrary. In principle, any pin could be used for a heater or device power. Should I add every conceivable pin, or just the one I happen to be using?

I like the idea of a configuration to set homing order. (I felt a little odd adding such a specific flag variable as PCBSCRIBER anyway.) This would require changes to the configtool though. Also, it's not just the axis order that should be specified, but whether home for each is at min or max as well. The current home() function seems to assume there's just one of each, but at least in my case, I have a Z_MIN and a Z_MAX.

[Traumflug]

Should I add every conceivable pin, or just the one I happen to be using?

Every conceivable pin, please.

And fixing typos right in the commit where it happened is a good idea. This topic branch is yours, so modifying history there won't cause conflicts.

[Traumflug]

#undef DEFINE_HOMING
#define DEFINE_HOMING(first, second, third) \
  home_ ## first ##_negative();
  home_## first ##_positive();
.
.
#undef DEFINE_HOMING

See me surprised to see that Teacup features this. Are you sure? Sounds like Configtool should write such definitions, too. It feels like there's a need for a tab dedicated to printer dimensions and endstop positions.

[Wurstnase]

No, someone needs to write this lines of code. It was just an idea how to do it in a more general way. Traumflug notifications@github.com schrieb am Sa. 19. Nov. 2016 um 10:49:

undef DEFINE_HOMING

define DEFINE_HOMING(first, second, third) \

home_ ## first ##negative(); home## first ##_positive(); . .

undef DEFINE_HOMING

See me surprised that Teacup features this. Are you sure? Sounds like Configtool should write such definitions, too. It feels like there's a need for a tab dedicated to printer dimensions and endstop positions.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/251#issuecomment-261704190, or mute the thread https://github.com/notifications/unsubscribe-auth/AITlJ2JSXwTToYTyhelbLKaf-7GbU8doks5q_sYygaJpZM4K2-Op .

[AnHardt]

The current home() function seems to assume there's just one of each, but at least in my case, I have a Z_MIN and a Z_MAX.

The direction, whether to home to min or max, could be described by the case of the letter.

x -> home to min. X -> home to max.

[Wurstnase]

Or simple call it x_min and x_max. No need to make any magic :)

[mattgilbertnet]

Edit: cleaned it up a bit, only changes are to home(), and DEFINE_HOMING in printer.xx.h is optional.

I've implemented home axis ordering, with the options being "x_negative", "x_positive", etc.

Side note, probably a separate issue: Has anyone used Teacup for a delta printer? I assume they would need to home all axes simultaneously.

[mattgilbertnet]

Since I made kind of a mess of the history with the "pcbscriber" branch, I created a different branch called "home_order" that's cleaner.

[Traumflug]

Thanks. For now I took this commit, rebased it to experimental and picked it onto there. Except this homing stuff, which I don't see ready for prime time, yet.

Matt, now you can rebase your branch to experimental. This reduces the commit to only the difference between _homeorder and experimental, which is the part still to be done. Obsolete branches can be removed. Locally with git branch -D pcbscriber, the remote branch with git push -f origin :pcbscriber (note the ':' )

[mattgilbertnet]

Ok, rebased home_order to experimental and deleted pcbscriber.

[Traumflug]

Thank you very much! Don't forget to push -f this rebased branch, else we don't see it.

Well, the situation about homing strategies. I feel a need for something user-definable. Currently the trend goes towards duplicate code (hardcoded vs. DEFINE_HOMING) and neither of them appears in Configtool. A few ideas (and I'm aware that expressing ideas without backing them with code is being cheap):

• Decouple Endstops from motor axes. Order them into a separate group in printer config files, give them a separate panel in Configtool.
• A graphical coordinate system drawn in Configtool with Pin definition menus and axis sizes drawn where they happen to be mounted on a real printer. Like what one would draw onto a piece of paper for explaining things to a neighbor. Eventually different graphics for karthesian/delta/scara printers.
• Get rid of the hardcoded homing strategy, always use DEFINE_HOMING. home.c would provide a set of primitives (functions for a single task), DEFINE_HOMING pick them up in the right order.
• There can be primitives for multiple axes as well, of course. Like home_xyz_negative(), which would move all three axes until one triggers. Deltas would then home to XYZ, then to X, then to Y, then to Z. Four steps for full homing.
• Add a column of 3 or 5 or 10 menus in this endstop panel in Configtool with these primitives, allowing the user to select them for building a homing strategy.

Does it sound like fun to draw something pretty into a panel? Glorious times for Python hackers ahead! A starter would be here and here.

[mattgilbertnet]

If you're not seeing it, I must not be rebasing or pushing correctly. tools/git-step-rebase experimental gives me:

fatal: Not a valid object name experimental

Common parent is .
fatal: ambiguous argument '..experimental': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
0 commits to go.
Will rebase current branch home_order to branch experimental.

IS THIS FINE?
If not, hit Ctrl-C now.
Waiting 5
Waiting 4
Waiting 3
Waiting 2
Waiting 1
All rebased.

Then pushing with git push -f origin home_order gives me Everything up-to-date.

[Wurstnase]

Maybe you've never downloaded experimental.

You could also use tools/git-step-rebase origin/experimental

[Traumflug]

This, or simply create experimental:

git checkout experimental

Git is nice enough to look for like-named remote branches when asked to checkout something.

[mattgilbertnet]

Tried is the way Wurstnase suggested, and it seemed to work.

[Wurstnase]

Looks very nice, your last approach! I would only rename "Homing" to "Homing order". What do you think?

[Traumflug]

Yes, exactly! Is this already written code?

[Wurstnase]

It is: https://github.com/Traumflug/Teacup_Firmware/commit/cb1d36393e1b984d6d597a890c77767d083adb96

[mattgilbertnet]

You guys have noticed, I started working on some of the low-hanging fruit here, adding homing order options to configtool (in the mechanical page for now).

I had to add an empty home_none() function to the firmware, which is not very elegant. I'm not familiar enough with preprocessing macros to avoid it, at the moment.

There's also a conflict getting in the way of rebasing to experimental. I'm a bit green on resolving stuff like that as well.

[mattgilbertnet]

I went ahead and changed "Homing" to "Homing Order".

[Wurstnase]

Rebasing is no problem for me and @Traumflug. You could also play with it.

When I want to rebase a new branch, I made first a copy of it with git checkout -b temp_branch. Then I do a tools/git-step-rebase origin/experimental.

When you have a conflict you can see the conflict files also with git status. Normally you have only conflicts in files you've modified.

[mattgilbertnet]

The conflict has to do with config/printer.pcbscriber.h. It's a file I added in the last commit, that was then added to experimental, then changed again in my most recent commit.

[Wurstnase]

Yes, the conflicts starts with <<<<<<. "Ours" and "theirs" is separated by ====== and finally ends with >>>>>>.

In your case the first part from <<<<<< to ======= is correct. Maybe the line with //#define Z_MAX is your's? Than keep it. After saving the file git add yourfile and git rebase --continue.

When it's all done, start again with tools/git-step-rebase origin/experimental until you finish without errors.

[Traumflug]

When you have a conflict you can see the conflict files also with git status.

This, and don't forget to use Gitk, like

gitk --all&

Seeing all the branches graphically gives them a lot more sense. Reload (Shift-F5) as needed.

If you're on Windows, Gitk comes with the normal Git distribution, so you likely have it already.

[mattgilbertnet]

Ok, I think I've finally tidied up the history. Thanks for your patience and tips as I learn to play nice with git.

[Wurstnase]

Close :) You should delete <<<<<< and the other lines.

You could make a rebase. git rebase -i HEAD\~2 That means you want to rebase interactive the last 2 commits of HEAD, which is that where you are currently.

An editor will start. There you will see something like:

pick e7c4e78 Homing order and pcbscriber config files
pick d8dfaf8 Integrated homing order options into configtool.

Replace pick with e or edit to edit that commit.

Save the file and close it. Now you are at the commit 2 before HEAD. Change the lines. Save them. git add . (don't forget the point) git rebase --continue Editor will start. Just close it, when you don't want to change the text of this commit.

Repeat until you are ready.

[mattgilbertnet]

Thanks for catching that. I think I've patched things up in a slightly different way, but are you suggesting I squash those two commits into one?

[Wurstnase]

Yes, you could also squash those two. The only different is the Z_MAX. Is 1000 correct? The height is 1m?

[mattgilbertnet]

The Z_MAX is arbitrarily huge, since the Z_max endstop is used to move the scriber down until it reaches a certain amount of pressure. From there, lifting and moving the scriber is accomplished by lifting to "990" or so.

[Wurstnase]

And why you need a z_max? Can't you go down if it's comment out? mattgilbertnet notifications@github.com schrieb am Mo. 28. Nov. 2016 um 23:39:

The Z_MAX is arbitrarily huge, since the Z_max endstop is used to move the scriber down until it reaches a certain amount of pressure. From there, lifting and moving the scriber is accomplished by lifting to "990" or so.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/251#issuecomment-263417675, or mute the thread https://github.com/notifications/unsubscribe-auth/AITlJ-H30hf43uKrPQ0s4qiwKhDdoJxyks5rC1g8gaJpZM4K2-Op .

[mattgilbertnet]

The z max endstop is used by the scriber, to stop moving down when there is a certain amount of pressure. So, instead of simply moving down to a certain spot, home_z_positive() is used, and that requires a Z_MAX value. The specific value of Z_MAX doesn't matter as long as it's A) larger than anything needed in normal operation, and B) the same as the value used by the gcode generator, which happens to be 1000.

[Wurstnase]

Hmmm... And why do you don't take x_min for this? On a 3D printer for example the position from the nozzle to the bed is the 0 position.

I'm currently thinking of some new gcode. Maybe we could use G30 which is going to be deleted anyway. G30 could move to an endstop without zeroing the position. This could be also useful to measure the accuracy of an endstop.

[mattgilbertnet]

If I used the pressure endstop for home, then the exact location of "home" would shift depending on how much pressure the scriber was set to have, which is adjusted manually. That would also shift the location of home for the drill, making the depth of the drill something that needed to be changed constantly. Also, the scriber is removed for the drilling step to get it out of the way, and this would make homing impossible while drilling. Instead, I chose to invert the z axis so that home is still at (0,0,0), and it's always at the same place.

Extra GCode commands is one way to do it, but since homing commands could accomplish the same task, it seemed like minimizing the changes the to (compiled) firmware would be preferred.

[Wurstnase]

Don't worry about my asking. I want to understand how you do it. But currently I have issues to understand how this will work for you. If this will work for you, everything is fine. :+1:

Do you use the max endstop only as a hard stop and not with G28? Where is Z0? Where is Z990 or something like that?

[mattgilbertnet]

No problem, this conversation will probably help me document it better! I've already produced a batch of endstop boards with this approach, so I can confirm it works.

I use the max endstop as a hard stop. So the gcode command for "apply pressure" is actually "home positive Z" (G162 Z).

Z0 is about 28mm above the point where the scriber hits the surface of the PCB. This gives enough room to remove the scriber out the bottom, or put it back in, then at home.

"Z990" is 10mm above where the scriber has enough pressure to trigger the endstop. Enough to lift and move the scriber between scratches, without dragging on the board.

Maybe this will help clarify things, here's the sequence:

• move the scriber to just above the surface where you want to begin scratching (Z=27 in my case, configurable in the gcode generator)
• G162 Z to hit the max endstop, a few mm further down, depending on the manual pressure setting (endstop position). The firmware now thinks it's at Z_MAX, or 1000.
• scratch by moving around in X and Y directions
• at the end of the scratch, G0 Z994 to lift the scriber far enough to stop scratching (also configurable)
• G92 Z27, the firmware now thinks it's at Z=27mm, which is pretty accurate.
• move to the next scratch, do the same thing starting with G162 Z...

There are also some "G4 P0" peppered in there to force queue_wait()s. I left them out for brevity.

[Wurstnase]

So you have only a Z_MIN for initial homing?

[mattgilbertnet]

Initial homing is done at x min, y min, and z min.

[Wurstnase]

Yes, X and Y is what I've understand. But you will only touch Z_MIN when you start the machine. After doing a G162 you could "remove" the Z_MIN and your machine will still work as you described? Or do you also use G28 afterwards maybe for your driller?

Does your solution also work, if you use Z_MAX for initial home at Z27 maybe? Then a G161 Z to scratch. G28 Z again for 'normal' position. Take the driller and drill your holes from Z27 to Z0. Would this close the same? Just for my understanding.

[mattgilbertnet]

I have it go home before and after scratching, and before and after drilling. (These steps are two separate "prints", separate gcode files, because the boards are etched in between.) I also have it go home occasionally during a print to calibrate, but this is a hold-over from my previous machine, which would go out of alignment from time to time. Homing during a print is something I'm sort of phasing out, since this setup doesn't seem to need it.

There's probably a way to do it with home at (0,0,27), or something along those lines. The drill is higher than the scriber, though, meaning drilling moves would go into negative Z. I found it simpler and more intuitive to have "home" be (0,0,0), and "home" also be when the scriber is lifted, like thinking of a pen or pencil being "at rest" when it's not making a mark. And Z values become increasing "depth". I don't know how typical this approach is for plotters or similar machines, just what made sense to me.

[Wurstnase]

My thinking is more mathematically, where you have the right-hand rule and z is top.

Do you mean like: G28 before scratch G162 Z move for scratching down G1 xxx scratching G1 Z990 move between some moves Z upwards G1 xxx scratching G28 after scratch ???

So how you drill currently? At Z990? Is this more logic than Z0? Maybe Z_MAX is at 30, so you don't need to go below zero.

[mattgilbertnet]

Pretty much.

Drilling doesn't use the max endstop at all. It's just

• G28 to home
• move the drill to just above the surface at the first drill point. (35.5mm in my current configuration)
• M106 S255 to turn on the drill
• move down to drill through the board (Z37.5 in my current configuration)
• move back up to 35.5
• M106 S0 to turn the drill off,
• ...

I can share gcode files output by the generator if you like.

[mattgilbertnet]

I wasn't worried about the right hand rule at all when I designed this, and I'm not sure what the best way to try to follow it would be, if that's important. I have the X and Y axes consistent with the convention for svgs, since that's what the gcode is generated from. Origin in top left, X increasing going right, Y increasing going "down" (towards you if you're looking down onto the stage from the front of the printer). So to follow the right hand rule, Z should increase going down into the bed, unless I'm mistaken.

[triffid]

I don't believe it matters if you use a left or right handed coordinate system, you just need your machine to follow whatever your gcode generator expects it to do

On 30 Nov 2016 06:26, "mattgilbertnet" notifications@github.com wrote:

I wasn't worried about the right hand rule at all when I designed this, and I'm not sure what the best way to try to follow it would be, if that's important. I have the X and Y axes consistent with the convention for svgs, since that's what the gcode is generated from. Origin in top left, X increasing going right, Y increasing going "down" (towards you if you're looking down onto the stage from the front of the printer). So to follow the right hand rule, Z should increase going down into the bed, unless I'm mistaken.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Traumflug/Teacup_Firmware/issues/251#issuecomment-263720231, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKBGsXe6snwq69oRk-JwI_leRuWcP6hks5rDKaJgaJpZM4K2-Op .

[Wurstnase]

Yes and no. Right-hand system is a worldwide standard. A lot users will not notice this, maybe, but people how are aware of it will be confused.

[Wurstnase]

Origin in top left, X increasing going right, Y increasing going "down" (towards you if you're looking down onto the stage from the front of the printer). So to follow the right hand rule, Z should increase going down into the bed, unless I'm mistaken.

If it's so, you are already in a right hand system.

On my printer origin is front left. My nozzle goes relative to the bed right to increase X and back to increase Y. So when the bed would move in Y the bed is in a back position (nozzle front) at 0 and the bed will move forward (nozzle is now back) to increase Y in positive direction.

[Traumflug]

About an hour ago I reviewed and moved branch home_order to experimental. Thank you very much for this contribution!

Closing this issue, because it's either solved or the discussion became too large to see what's still missing. In case there's something to do left, or something new coming up, please don't hesitate to open a new issue.