How to assign ACTUATOR_READ_COMMAND to an actuator
V Bruce Hunt
ma...@makr.zone
Hi Bruce
Thanks for the feedback.
> The ACTUATOR_READ_COMMAND is assigned to driver GcodeDriver albeit empty.
No, nothing is assigned by the solution, it is just a friendly reminder and link to the Wiki. The GcodeDriver GUI will simply always show all possible entries, those that are missing are shown as empty.
> Should the solution to the issue be something like...?
This is Open Source and you're part of the community. π So
please contribute to the linked Wiki.
Everybody can write to it.
That's one of the reasons, these solutions link to the Wiki, so
the linked instructions can be improved and knowledge from the
community collected, even without having to modify OpenPnP itself
(and having to know Java).
When you do provide G-code examples π, please make sure to state for which type of controller/firmware it is, and for which which Actuator it is intended (small FETs for this, big FETs for that). Thanks!
Once there is a good collection/consensus of how to assign
actuator commands, we can think about automating even this inside
OpenPnP.
_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/41d08712-96fd-4f2c-b726-b020bdf9ea19n%40googlegroups.com.
Roman Valls
mark maker
Off the top of my head, the Liteplacer contact probe is never read. So is it possible, you confused Z probe with contact probe?
I know having these two solutions is a bit confusing both in name and application, but they simply are not the same.
https://github.com/openpnp/openpnp/wiki/Z-Probing
vs.
https://github.com/openpnp/openpnp/wiki/Contact-Probing-Nozzle#contact-sense-method
NOTE: unlike for other actuators, Issues & Solutions provides
full contact probe actuator support for Smoothieware and TinyG.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/da153a60-d296-42a1-8f62-30a1255ee13cn%40googlegroups.com.
Roman Valls
---------- Forwarded message ---------
From: Roman Valls <brain...@nopcode.org>
Date: Wed, Dec 29, 2021 at 7:50 PM
Subject: Re: [OpenPnP] How to assign ACTUATOR_READ_COMMAND to an actuator
To: <ope...@googlegroups.com>
That was exactly right Mark, thanks, this unlocked a bunch of progress
where I was really stuck before! :)
That difference you pointed out was not clear to me at all, I thought
they were the same thing. In my new understanding, the "Z max" limit
switch in the LitePlacer acts as a "Contact Probe Nozzle".
Now, while we are at it, I would like to ask a couple of (basic?)
additional questions...
1) When I push the Zmax limit switch on my liteplacer, should the M114
G-Code command return something different so that OpenPnP knows it has
been actuated? In other words, what's the expected output of M114 when
the "N1:PROBE" switch is actuated?
2) Where does that limit switch actually get wired for things to work
properly with this specific configuration in the TinyG board? Zmax?
Amin/Amax?
I've attached a few photos to clarify the context, I hope I'm being
precise enough with those questions? Thanks a ton in advance!
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/9CGRdNgd8qk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fdc67511-1cc6-381d-8daa-e09b755860ee%40makr.zone.
mark maker
1)
Contact probing works indirectly. It moves the nozzle
down until the switch is activated, then stops. It basically works
like homing. It then uses M114 to
get the Z axis position, which tells it where the probed Z contact
happened. But M114 itself is a
general purpose command to get the current machine position, i.e.
it does not report or care about any switches.
If you want to read the switch, you would use M119 on the Smoothie but for TinyG I don't actually know. Again, that is never used by OpenPnP, i.e. the probing is done internally in real-time by the controller (as in homing too).
2)
You'd have to consult the TinyG or Liteplacer documentation
regarding pull-up/pull-down, NC, NO configuration.
_Mark
Roman Valls
For context, I'm using the firmware you published in:
https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/ on a
the board that comes with the LitePlacer default kit.
Actually, I might have catched a regression? See attached screenshot,
I can reproduce that NPE message when trying to "Detect Firmware" in
OpenPnP release 2021-12-14_20-12-13.f82785d. This button used to work
just fine in previous releases, filling the box with firmware string
details... hm. I'll look at which raw command is sent from the source
code.
1) Understood! Unfortunately the M119 command returns "from
controller: tinyg [mm] err: M Code unsupported: M119" ? And in the
G-Code console itself, there's no response (as you can see in the
screenshots) :/ This is consistent with the near-catastrophic behavior
of the machine when I was testing the "touch location", I had to do an
emergency stop because that switch actuation was not being
triggered/seen in OpenPnP at all, so the nozzle tip kept pushing on
without stopping :/
2) I re-checked and I reckon that the connections are ok and it's in
NO configuration, the wiring looks fine... I now need a reliable
command to check the status of that particular switch. I'll review the
current OpenPnP code and docs for the ContactProbeNozzle to gain
better understanding and also issue some more M commands to the board
to see how it responds in raw.
Thanks again!
Roman
Roman Valls
parses the M115 output:
https://github.com/openpnp/openpnp/blob/develop/src/main/java/org/openpnp/machine/reference/driver/GcodeDriver.java#L1576
I can still reproduce the issue (see screenshots). For more context,
the machine has been powered on but not homed (because I still need to
fix the M119/contactprobe issue)... mentioning this in case you want
to reproduce this issue.
Roman Valls
https://github.com/markmaker/TinyG/blob/master/firmware/tinyg/canonical_machine.h
... that command is specific to the Smoothie one and there doesn't
seem to be an equivalent (that I can easily find) for TinyG.
This might sound like a very basic question, but I don't (yet)
understand how the ContactProbeNozzle leverages that "internally
controlled by the controller" nozzle switch on the LitePlacer... my
current mental model about it is:
1) Nozzle tip "Calibrate" goes down on the "Touch location" until it
triggers the Zmax limit switch.
2) OpenPnP notices that limit triggering from the board and then
issues a M114 command to parse the current Z coordinate at the
location switched in 1.
3) Those coordinates are stored both on machine.xml and on memory
during the current job for Z level operations (component height
auto-learning, etc..).
I'll now go and read some of the contact probe OpenPnP code to
understand this better because I'm not 100% clear as to how this works
with TinyG (if at all?) by reading the wiki docs :)
Sorry for the verbosity, this helps me understand and document my
findings as I investigate this.
Roman Valls
incorrectly connected as NC instead of NO. Fixed that now. The "Detect
Firmware" button also works **after homing**. If the machine is not
homed, NPE occurs.
mark maker
> Disregard the whole contactprobe issue, the limit switch was indeed incorrectly connected as NC instead of NO. Fixed that now.
Glad this has been sorted out. But NC would actually be better electrically and on the safer side (in case the cable breaks). There is a config option to configure the switch ;-)
I agree that TinyG could do well with a diagnostic command (like M119) to list the switch states. But again such a command is not needed during operation with OpenPnP.
> my current mental model about it is:
> 1) Nozzle tip "Calibrate" goes down on the "Touch location"
until it triggers the Zmax limit switch.
> 2) OpenPnP notices that limit triggering from the board and
then issues a M114 command to parse the current Z coordinate at
the location switched in 1.
No, it works like this:
- OpenPnP tells the controller to do the probing.
- OpenPnP tells the controller to wait for motion to complete (M400). This will block the "ok" back
from the controller until it happened.
- Nozzle tip goes down on the "Touch location" until it triggers the Zmax limit switch.
- The controller autonomously notices this in real-time
and immediately stops the motor, i.e., without any non-real-time
USB communication back and forth needed (UBS comms would not be
reliable, the nozzle could crash).
- The controller now sends the "ok" blocked by the M400 in (2).
- OpenPnP now send M114 to report the current position.
- The controller sends the current position, which contains the
probed Z.
> Actually, I might have catched a regression? See attached screenshot
mark maker
Disregard what I said about TinyG switch configuration. For
probing, only NO works:
Note that probing cycles (G38.2) will work regardless of the switch setting. Probing (currently) assumes a normally open switch in the Z minimum position. During the probe cycle switches are set to NO (and ignored). They are restored to their actual $st setting when probing is complete.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e7d21b3c-92b0-8b72-eb40-5ce6b1de7405%40makr.zone.
Roman Valls
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e7d21b3c-92b0-8b72-eb40-5ce6b1de7405%40makr.zone.
Roman Valls
that there aren't any. Also no logs nor trace indicating that a query
or check has been made against the remote update(s) location, my
current release is: "2021-12-14_20-12-13.f82785d".
I just noticed that ~8h ago you pushed a new release through GitHub
actions?: https://github.com/openpnp/openpnp/runs/4668272456
My installation doesn't seem to pick those up either though :/ ... ah!
I just noticed that the object is still not there in (the latest being
my current install):
https://openpnp.s3-us-west-2.amazonaws.com/index.html?prefix=develop
mark maker
There are two branches, develop and test. You
seem to be on develop, I thought you are on test.
https://openpnp.org/test-downloads/
It seems I need to cherry pick that change to develop.
_Mark
mark maker
This is now also fixed in the develop branch. You should be able to upgrade.
Obviously, you could also switch to the test branch, to help test the new cool features (and benefit from them). π
https://openpnp.org/test-downloads/
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1e4055af-99fd-9302-4f6f-6aded37860ad%40makr.zone.
Roman Valls
edge branch, but yeah, happy to switch to testing if that's where the
fun stuff is happening ;)