Advanced Motion Control - TInyG - ADC support
Michael Schober
ma...@makr.zone
Hi Michael
That's unfortunate. I've tried to use the patch that was pasted
into that post, but it does not work. Well frankly I don't know
much about patches, just tried with the Tortoise git patch menu.
I've asked in the forum:
https://www.liteplacer.com/phpBB/viewtopic.php?p=10149#p10149
I don't know if TinyG has a different way to read the ADC. There
seems to be no documentation.
https://github.com/synthetos/TinyG/wiki/Gcode-Support
@Tony?
_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/3bc60f94-ae01-4090-8564-e750bfb46025n%40googlegroups.com.
johanne...@formann.de
tony...@att.net
ma...@makr.zone
Hi Michael and Johannes
I brought the ADC back! You should now be able to use the newest
OpenPnP features too ;-)
NOTE: I decided TinyG should really use to the quasi-standard
M105 command like all the other controllers and not the
proprietary json. I plan to add vacuum actuator G-code
configurations to be proposed by Issues & Solutions in the
future, so I prefer a common base.
For now, you need to reconfigure the ACTUATOR_READ_COMMAND and ACTUATOR_READ_REGEX as documented here:
https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/
Could you please test it (including the
G-code config)? Thanks!
Don't forget to backup first.
Or if you have the
newest OpenPnP testing version (recommended) check if the
new automatic backups really work:
_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/faa8ed7b-9db5-462b-870a-8013e6038f9dn%40googlegroups.com.
james.edwa...@gmail.com
Hi, Mark. The link https://makr.zone/TinyG.7z seems to be empty. And could you expand a little on how to reprogram the TinyG? As I understand it this step is necessary to use the newest Openpnp2 ?
Best, Jim
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/73334fc6-433d-f899-9fd2-c7ca01fe232f%40makr.zone.
ma...@makr.zone
> The link https://makr.zone/TinyG.7z seems to be empty.
Sorry about that, fixed.
> And could you
expand a little on how to reprogram the TinyG?
I have added more instructions in the post, under "Flashing the TinyG":
https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/
> As I understand it this step is necessary to use the newest Openpnp2 ?
Theoretically it should work with
the old firmware, but I just got an error report...
So yes, it is highly recommended
to upgrade the new firmware. You will miss out on many features,
otherwise.
One example:
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/05d101d6f352%24902f38d0%24b08daa70%24%40gmail.com.
james.edwa...@gmail.com
Thanks, Mark. Two last questions: Is the new firmware backward compatible with older versions of OpenPnP? Also is there any to revert the firmware back to original (if there are problems)?
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/56903315-6dd7-d0b3-04e6-5a8fda0c1ea2%40makr.zone.
johanne...@formann.de
Clemens Koller
Flashing Mark's Firmware can be done on Linux as well with avrdude. Backup your settings before!
Just don't forget to start avrdude while the red LED on TinyG is still flashing after hitting the reset button.
Downgrading should also be possible in the same way.
It is propably a wise idea to reset TinyG to factory defaults after a firmware change with $defa=1. Backup your settings before!
$ md5sum tinyg.hex
a412c73a63f0b0ce24ec00c9a99bd64a tinyg.hex
$ avrdude -v
avrdude: Version 6.3, compiled on Jul 7 2020 at 19:38:43
[...]
$ avrdude -p x192a3 -c avr109 -b 115200 -P /dev/ttyUSB0 -e -U flash:w:tinyg.hex
Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.
Programmer supports the following devices:
Device code: 0x7b
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9744 (probably x192a3u)
avrdude: erasing chip
avrdude: reading input file "tinyg.hex"
avrdude: input file tinyg.hex auto detected as Intel Hex
avrdude: writing flash (119420 bytes):
Writing | ################################################## | 100% 12.88s
avrdude: 119420 bytes of flash written
avrdude: verifying flash memory against tinyg.hex:
avrdude: load data flash data from input file tinyg.hex:
avrdude: input file tinyg.hex auto detected as Intel Hex
avrdude: input file tinyg.hex contains 119420 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 11.24s
avrdude: verifying ...
avrdude: 119420 bytes of flash verified
avrdude done. Thank you.
Greets,
Clemens
On 25/01/2021 21.26, ma...@makr.zone wrote:
> /> //The link https://makr.zone/TinyG.7z <https://makr.zone/TinyG.7z> seems to be empty./
>
> Sorry about that, fixed.
>
> /> //And could you expand a little on how to reprogram the TinyG? /
> I have added more instructions in the post, under "Flashing the TinyG":
>
>
> /> As I understand it this step is necessary to use the newest Openpnp2 ?/
> Theoretically it should work with the old firmware, but I just got an error report...
>
> So yes, it is highly recommended to upgrade the new firmware. You will miss out on many features, otherwise.
>
> One example:
>
>> Hi, Mark. The link https://makr.zone/TinyG.7z <https://makr.zone/TinyG.7z> seems to be empty. And could you expand a little on how to reprogram the TinyG? As I understand it this step is necessary to use the newest Openpnp2 ?
>>
>> Best, Jim
>>
>>
>>
>>
>>
>> *From:* ope...@googlegroups.com <ope...@googlegroups.com> *On Behalf Of *ma...@makr.zone
>> *Sent:* Monday, January 25, 2021 10:59 AM
>> *To:* ope...@googlegroups.com
>> *Subject:* Re: [OpenPnP] Re: Advanced Motion Control - TInyG - ADC support
>>
>>
>> Hi Michael and Johannes
>>
>> I brought the ADC back! You should now be able to use the newest OpenPnP features too ;-)
>>
>> For now, you need to reconfigure the ACTUATOR_READ_COMMAND and ACTUATOR_READ_REGEX as documented here:
>>
>> Could you please test it (including the G-code config)? Thanks!
>>
>> Or if you have the newest OpenPnP testing version (recommended) check if the new automatic backups really work:
>>
>>
>>
>>
>> Am 23.01.2021 um 16:07 schrieb tony...@att.net <mailto:tony...@att.net>:
>>
>> I don't use a vacuum sensor so I'm of no help - I think I remember reading somewhere that a physical modification to the TInyG was necessary but I could be wrong on that.
>>
>>
>>
>> Tony
>>
>>
>> Thanks for testing it. Was thinking about the update too, but also depend on the ADC for the vacuum sensor.
>>
>> Michael Schober schrieb am Samstag, 23. Januar 2021 um 10:27:25 UTC+1:
>>
>> Mark,
>>
>>
>>
>> I tried to follow your advise for the TinyG firmware to use the Advanced Motion Control.
>>
>>
>>
>> But finally I detected, that in the TinyG Firmware Update the ADC path isn't working (anymore).
>>
>>
>>
>>
>> https://www.liteplacer.com/phpBB/viewtopic.php?f=10&t=154 <https://www.liteplacer.com/phpBB/viewtopic.php?f=10&t=154>
>>
>>
>> Could it be, that the ADC is supported using different commands than the "$ADC0" command?
>>
>>
>>
>> Michael
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/faa8ed7b-9db5-462b-870a-8013e6038f9dn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/faa8ed7b-9db5-462b-870a-8013e6038f9dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> --
>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/73334fc6-433d-f899-9fd2-c7ca01fe232f%40makr.zone <https://groups.google.com/d/msgid/openpnp/73334fc6-433d-f899-9fd2-c7ca01fe232f%40makr.zone?utm_medium=email&utm_source=footer>.
>> --
>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/05d101d6f352%24902f38d0%24b08daa70%24%40gmail.com <https://groups.google.com/d/msgid/openpnp/05d101d6f352%24902f38d0%24b08daa70%24%40gmail.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/56903315-6dd7-d0b3-04e6-5a8fda0c1ea2%40makr.zone <https://groups.google.com/d/msgid/openpnp/56903315-6dd7-d0b3-04e6-5a8fda0c1ea2%40makr.zone?utm_medium=email&utm_source=footer>.
ma...@makr.zone
> Is the new
firmware backward compatible with older versions of OpenPnP?
Yes.
> Also is there any to revert the firmware back to original (if there are problems)?
Yes.
https://github.com/synthetos/TinyG/wiki/TinyG-TG-Updater-App
Or
even more options here:
https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmware
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/05df01d6f35b%24ee9a2020%24cbce6060%24%40gmail.com.
ma...@makr.zone
> Any code/features currently in the testing version, that probably won't make it into "main"?
Certainly none planned ;-)
> Asking since I had get my HeapFeeder into testing to test it on my machine, and I guess that will be a bit of work (about 8 Month development to catch up).
If you used git to track it, I see no problem to merge the new
test branch back into your branch.
There were few feeder related changes. I remember only two:
- Better diagnostics on the pipeline results (assume you have
vision). You can look at the other pipeline usages to see what
changed. If you leave it as is, that's also OK, just not so nice
diagnostics.
https://github.com/openpnp/openpnp/pull/1103
- When you have UI action buttons that deliberately targets a
Camera or Nozzle etc., add a call to
MovableUtils.fireTargetedUserAction(tool);
This will auto-select the tool in Machine Controls, switch ON the camera light and capture a frame for 0fps cameras (if so configured).
Are you planning to make a PR?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b967e0d9-6015-4b91-968f-b6d5a759bdben%40googlegroups.com.
Michael Schober
ma...@makr.zone
Thanks Clemens,
AQEX also listed how to install avrdude if it is missing:
https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/#comment-172
> It is propably a wise idea to reset TinyG to factory
defaults after a firmware change with $defa=1. Backup your
settings before!
I recommend against $defa=1! You risk losing settings you may not remember having made. At least be sure to have made a backup of the settings using $$ and you know how to restore them.
Factory defaults should only be needed if your version is very,
very old. TinyG has a stable persistence system to make sure the
EEPROM is upwards compatible.
My firmware does not change the EEPROM structure or contents at
all (up from original master firmware version 0.97, build 440.20).
This means you can also go back to the original firmware, without
any problems.
_Mark
johanne...@formann.de
> Asking since I had get my HeapFeeder into testing to test it on my machine, and I guess that will be a bit of work (about 8 Month development to catch up).If you used git to track it, I see no problem to merge the new test branch back into your branch.
There were few feeder related changes. I remember only two:
Are you planning to make a PR?
ma...@makr.zone
Re https://github.com/openpnp/openpnp/pull/998
You'll find the new DirectionalCompensation useful.
https://github.com/openpnp/openpnp/wiki/Backlash-Compensation
No more need to choose SpeedOverPrecision (only the old backlash comp
methods are suppressed by it).
The constant has moved:
_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/671abc30-9cce-4a8a-b5e9-ea828886c563n%40googlegroups.com.
Clemens Koller
On 26/01/2021 08.54, ma...@makr.zone wrote:
> AQEX also listed how to install avrdude if it is missing:
You could extend this, if you want, for Arch Linux:
$ pacman -S avrdude
>
> /> It is propably a wise idea to reset TinyG to factory defaults after a firmware change with $defa=1. Backup your settings before! //
> /
> I recommend against $defa=1! You risk losing settings you may not remember having made. At least be sure to have made a backup of the settings using $$ and you know how to restore them.
> Factory defaults should only be needed if your version is very, very old. TinyG has a stable persistence system to make sure the EEPROM is upwards compatible.
> My firmware does not change the EEPROM structure or contents at all (up from original master firmware version 0.97, build 440.20). This means you can also go back to the original firmware, without any problems.
https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/
Because:
"CAUTION: although this has been created with great care, flashing your TinyG and then using the machine is entirely at your own risk."
Definitely tells that anything beyond the is questionable.
Clemens
On 26/01/2021 08.54, ma...@makr.zone wrote:
> Thanks Clemens,
>
> AQEX also listed how to install avrdude if it is missing:
>
> /> It is propably a wise idea to reset TinyG to factory defaults after a firmware change with $defa=1. Backup your settings before! //
> /
ma...@makr.zone
You could extend this, if you want, for Arch Linux:
$ pacman -S avrdude
Best add a comment yourself, please. So it is properly credited ;-)
https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/_Mark
ma...@makr.zone
It would be good to put that information of a persistant EEPROM system into: https://makr.zone/tinyg-new-g-code-commands-for-openpnp-use/577/
Yes, good idea. Done.
Because: "CAUTION: although this has been created with great care, flashing your TinyG and then using the machine is entirely at your own risk."
Yes, the disclaimer... :-/
Frankly, I have no idea how dangerous it is. I just assumed that
if hobbyists all over the world use the same tools under the hood
of the Arduino IDE, it can't be that easy to brick. But
maybe I'm mistaken?
_Mark
Jim Freeman
2021-01-27 14:47:11.198 ReferenceMachine DEBUG: setHomed(false)
2021-01-27 14:47:11.203 ReferenceHead DEBUG: H1.home()
2021-01-27 14:47:11.204 GcodeDriver DEBUG: sendCommand(G28.2 X0 Y0 Z0 A0, -1)...
2021-01-27 14:47:11.211 GcodeDriver DEBUG: sendCommand(serial://COM3 G28.2 X0 Y0 Z0 A0, -1) => [tinyg [mm] ok>]
2021-01-27 14:47:11.212 GcodeDriver DEBUG: sendCommand(G92 X0 Y0 Z0, -1)...
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/cfca9dd5-8bc2-4eb1-49f1-4d3c87f7bf37%40makr.zone.
Jim Freeman
G28.2 X0 Y0 Z0 A0
> M115
tinyg [mm] ok>
[fb] firmware build 440.21
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
[id] TinyG ID 7W4698-3DK
[ja] junction acceleration 100000 mm
[ct] chordal tolerance 0.0100 mm
[sl] soft limit enable 0
[st] switch type 0 [0=NO,1=NC]
[mt] motor idle timeout 300.00 Sec
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 2 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[js] json serialize style 1 [0=relaxed,1=strict]
[tv] text verbosity 1 [0=silent,1=verbose]
[qv] queue report verbosity 0 [0=off,1=single,2=triple]
[sv] status report verbosity 2 [0=off,1=filtered,2=verbose]
[si] status interval 500 ms
[ec] expand LF to CRLF on TX 0 [0=off,1=on]
[ee] enable echo 0 [0=off,1=on]
[ex] enable flow control 1 [0=off,1=XON/XOFF, 2=RTS/CTS]
[baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
[net] network mode 0 [0=master]
[gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
[gun] default gcode units mode 1 [0=G20,1=G21]
[gco] default gcode coord system 1 [1-6 (G54-G59)]
[gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 0 [0=G90,1=G91]
[1ma] m1 map to axis 0 [0=X,1=Y,2=Z...]
[1sa] m1 step angle 0.900 deg
[1tr] m1 travel per revolution 39.9820 mm
[1mi] m1 microsteps 10 [1,2,4,8]
[1po] m1 polarity 0 [0=normal,1=reverse]
[1pm] m1 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z...]
[2sa] m2 step angle 0.900 deg
[2tr] m2 travel per revolution 39.9700 mm
[2mi] m2 microsteps 10 [1,2,4,8]
[2po] m2 polarity 0 [0=normal,1=reverse]
[2pm] m2 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[3ma] m3 map to axis 2 [0=X,1=Y,2=Z...]
[3sa] m3 step angle 1.800 deg
[3tr] m3 travel per revolution 8.0000 mm
[3mi] m3 microsteps 8 [1,2,4,8]
[3po] m3 polarity 1 [0=normal,1=reverse]
[3pm] m3 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[4ma] m4 map to axis 3 [0=X,1=Y,2=Z...]
[4sa] m4 step angle 0.900 deg
[4tr] m4 travel per revolution 160.0000 mm
[4mi] m4 microsteps 8 [1,2,4,8]
[4po] m4 polarity 0 [0=normal,1=reverse]
[4pm] m4 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[xam] x axis mode 1 [standard]
[xvm] x velocity maximum 10000 mm/min
[xfr] x feedrate maximum 10000 mm/min
[xtn] x travel minimum 0.000 mm
[xtm] x travel maximum 150.000 mm
[xjm] x jerk maximum 1000 mm/min^3 * 1 million
[xjh] x jerk homing 1000 mm/min^3 * 1 million
[xjd] x junction deviation 0.0500 mm (larger is faster)
[xsn] x switch min 3 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] x switch max 2 [0=off,1=homing,2=limit,3=limit+homing]
[xsv] x search velocity 1000 mm/min
[xlv] x latch velocity 100 mm/min
[xlb] x latch backoff 5.000 mm
[xzb] x zero backoff 1.000 mm
[yam] y axis mode 1 [standard]
[yvm] y velocity maximum 10000 mm/min
[yfr] y feedrate maximum 10000 mm/min
[ytn] y travel minimum 0.000 mm
[ytm] y travel maximum 150.000 mm
[yjm] y jerk maximum 1000 mm/min^3 * 1 million
[yjh] y jerk homing 1000 mm/min^3 * 1 million
[yjd] y junction deviation 0.0500 mm (larger is faster)
[ysn] y switch min 3 [0=off,1=homing,2=limit,3=limit+homing]
[ysx] y switch max 2 [0=off,1=homing,2=limit,3=limit+homing]
[ysv] y search velocity 1000 mm/min
[ylv] y latch velocity 100 mm/min
[ylb] y latch backoff 5.000 mm
[yzb] y zero backoff 1.000 mm
[zam] z axis mode 1 [standard]
[zvm] z velocity maximum 1000 mm/min
[zfr] z feedrate maximum 1000 mm/min
[ztn] z travel minimum 0.000 mm
[ztm] z travel maximum 75.000 mm
[zjm] z jerk maximum 200 mm/min^3 * 1 million
[zjh] z jerk homing 500 mm/min^3 * 1 million
[zjd] z junction deviation 0.0500 mm (larger is faster)
[zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max 3 [0=off,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity 1000 mm/min
[zlv] z latch velocity 100 mm/min
[zlb] z latch backoff 5.000 mm
[zzb] z zero backoff 2.000 mm
[aam] a axis mode 3 [radius]
[avm] a velocity maximum 300000 deg/min
[afr] a feedrate maximum 300000 deg/min
[atn] a travel minimum -1.000 deg
[atm] a travel maximum -1.000 deg
[ajm] a jerk maximum 25000 deg/min^3 * 1 million
[ajh] a jerk homing 11520 deg/min^3 * 1 million
[ajd] a junction deviation 0.0500 deg (larger is faster)
[ara] a radius value 0.1989 deg
[asn] a switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[asx] a switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[asv] a search velocity 600 deg/min
[alv] a latch velocity 100 deg/min
[alb] a latch backoff 5.000 deg
[azb] a zero backoff 2.000 deg
[bam] b axis mode 0 [disabled]
[bvm] b velocity maximum 3600 deg/min
[bfr] b feedrate maximum 3600 deg/min
[btn] b travel minimum -1.000 deg
[btm] b travel maximum -1.000 deg
[bjm] b jerk maximum 20 deg/min^3 * 1 million
[bjd] b junction deviation 0.0500 deg (larger is faster)
[bra] b radius value 1.0000 deg
[cam] c axis mode 0 [disabled]
[cvm] c velocity maximum 3600 deg/min
[cfr] c feedrate maximum 3600 deg/min
[ctn] c travel minimum -1.000 deg
[ctm] c travel maximum -1.000 deg
[cjm] c jerk maximum 20 deg/min^3 * 1 million
[cjd] c junction deviation 0.0500 deg (larger is faster)
[cra] c radius value 1.0000 deg
[p1frq] pwm frequency 100 Hz
[p1csl] pwm cw speed lo 1000 RPM
[p1csh] pwm cw speed hi 2000 RPM
[p1cpl] pwm cw phase lo 0.125 [0..1]
[p1cph] pwm cw phase hi 0.200 [0..1]
[p1wsl] pwm ccw speed lo 1000 RPM
[p1wsh] pwm ccw speed hi 2000 RPM
[p1wpl] pwm ccw phase lo 0.125 [0..1]
[p1wph] pwm ccw phase hi 0.200 [0..1]
[p1pof] pwm phase off 0.100 [0..1]
[g54x] g54 x offset 0.000 mm
[g54y] g54 y offset 0.000 mm
[g54z] g54 z offset 0.000 mm
[g54a] g54 a offset 0.000 deg
[g54b] g54 b offset 0.000 deg
[g54c] g54 c offset 0.000 deg
[g55x] g55 x offset 75.000 mm
[g55y] g55 y offset 75.000 mm
[g55z] g55 z offset 0.000 mm
[g55a] g55 a offset 0.000 deg
[g55b] g55 b offset 0.000 deg
[g55c] g55 c offset 0.000 deg
[g56x] g56 x offset 0.000 mm
[g56y] g56 y offset 0.000 mm
[g56z] g56 z offset 0.000 mm
[g56a] g56 a offset 0.000 deg
[g56b] g56 b offset 0.000 deg
[g56c] g56 c offset 0.000 deg
[g57x] g57 x offset 0.000 mm
[g57y] g57 y offset 0.000 mm
[g57z] g57 z offset 0.000 mm
[g57a] g57 a offset 0.000 deg
[g57b] g57 b offset 0.000 deg
[g57c] g57 c offset 0.000 deg
[g58x] g58 x offset 0.000 mm
[g58y] g58 y offset 0.000 mm
[g58z] g58 z offset 0.000 mm
[g58a] g58 a offset 0.000 deg
[g58b] g58 b offset 0.000 deg
[g58c] g58 c offset 0.000 deg
[g59x] g59 x offset 0.000 mm
[g59y] g59 y offset 0.000 mm
[g59z] g59 z offset 0.000 mm
[g59a] g59 a offset 0.000 deg
[g59b] g59 b offset 0.000 deg
[g59c] g59 c offset 0.000 deg
[g92x] g92 x offset 0.000 mm
[g92y] g92 y offset 0.000 mm
[g92z] g92 z offset 0.000 mm
[g92a] g92 a offset 0.000 deg
[g92b] g92 b offset 0.000 deg
[g92c] g92 c offset 0.000 deg
[g28x] g28 x position 0.000 mm
[g28y] g28 y position 0.000 mm
[g28z] g28 z position 0.000 mm
[g28a] g28 a position 0.000 deg
[g28b] g28 b position 0.000 deg
[g28c] g28 c position 0.000 deg
[g30x] g30 x position 0.000 mm
[g30y] g30 y position 0.000 mm
[g30z] g30 z position 0.000 mm
[g30a] g30 a position 0.000 deg
[g30b] g30 b position 0.000 deg
[g30c] g30 c position 0.000 deg
--
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/72c2c36d-545c-25a0-4acc-81e508b3bcf9%40makr.zone.
tony...@att.net
johanne...@formann.de
Clemens Koller
I am quite regularly running into serious communication issues with TinyG + GcodeAsyncDriver when sending more than just a few $commands at once. It seems that TinyG cannot cope with back-to-back $commands even with RTSCTS flow control enabled!
Some Details are here: https://synthetos.com/topics/file-not-open-error#post-7194
I have no idea if this bug or issue is fixed in TinyG or not. My research is work-in-progress. If somebody can send me some TinyG+Liteplacer+OpenPnP+GcodeAsyncDriver configuration which is supposed to work, I could diff & merge even more.
Clemens
On 27/01/2021 22.24, tony...@att.net wrote:
> Can you set your logging level to trace and post the entire log file?
>
> On Wednesday, January 27, 2021 at 3:15:30 PM UTC-6 james.edwa...@gmail.com wrote:
>
> Hi, Mark. As I said I can't home after updating the TinyG firmware: Here is some more information:
>
> My HOME command is :
>
> G28.2 X0 Y0 Z0 A0
> G92 X0 Y0 Z0
>
> The TinyG result of M115 is
>
> > M115
> _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.
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e0a37b82-7a00-4c88-a21e-901fe19d0e7dn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/e0a37b82-7a00-4c88-a21e-901fe19d0e7dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
ma...@makr.zone
Hi Jim
I guess I must concede that in TinyG (unlike in the other
controllers) the migration "as is" has a bug. See this issue, and
the two options you have.
https://groups.google.com/g/openpnp/c/jhs-i3FMEj4/m/7TFXSBWVDQAJ
If you're willing to help me test this, I can try and fix the bug in an "as is" migration. Ideally you could send me the old machine.xml before the migration.
Otherwise I recommend the Issue & Solutions approach. This is
the future anyway.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyAEhvxF5oHCmtWVLN%2BWS1n-sqFEFbwqomiMg8p2UFRbvw%40mail.gmail.com.
ma...@makr.zone
I assume this is after Issues & Solutions?
https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions
Please send the machine.xml
_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/10569295-bb51-4b33-85cc-fd17dde8dce4n%40googlegroups.com.
ma...@makr.zone
Hi Clemens
Please send the machine.xml
_Mark
johanne...@formann.de
ma...@makr.zone
Have you enabled RTS/CTS Flow Control?
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#settings
Then you absolutely need $ex=2 in the CONNECT_COMMAND.
Clemens has reported it unreliable. If that's true (and not
another reason I actually suspect) then you TinyG users need to
enable Confirmation Flow Control.
Please report if that helps.
Confirmation Flow Control is slightly slower, but for
TinyG that's actually not a problem, because it has firmware Jerk
control, so it does not need to support the high-volume command
bursts needed for Jerk interpolation through Simulated3rdOrderControl.
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation
_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/e9ea01b0-e88f-484b-8f02-a3270e2d1379n%40googlegroups.com.
johanne...@formann.de
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e0a37b82-7a00-4c88-a21e-901fe19d0e7dn%40googlegroups.com.
ma...@makr.zone
Hi Johannes
I had a look at the machine.xml and tried it on my bare TinyG.
The only thing I found is it needed a longer connect wait:
Otherwise it would respond garbled (at least after power off). With your 1000ms:
2021-01-28 17:35:13.312
GcodeDriver$ReaderThread TRACE: [serial://COM10] <<
bﾂbﾚￂﾚ￪ￕ)�[tv] text verbosity 1
[0=silent,1=verbose]
Set to the default 3000ms it was still garbled but at least it
seemed to be the startup message only.
2021-01-28 17:44:11.388 GcodeDriver$ReaderThread TRACE: [serial://COM10] << ﾒ'L)ﾺﾂb 2ﾉﾉￒﾢﾢﾂrﾒﾊb Bﾉￒﾊb Bﾉￒￂb Jﾑﾉￒ ﾪￂ ￂﾪﾂj ￥U%ﾉIRkￗﾖ$'ﾤﾪV*UQSﾐﾩEADY"},"f":[1,0,0,383]}
With 5000ms it was ok.
2021-01-28 17:45:22.533
GcodeDriver$ReaderThread TRACE: [serial://COM10] <<
{"r":{"fv":0.970,"fb":440.21,"hp":1,"hv":8,"id":"5X0850-CNU","msg":"SYSTEM
READY"},"f":[1,0,0,383]}
IMPORTANT NOTE: Confirmation Flow
Control will only work, if each and every command is confirmed
with a "tinyg [mm] ok>". If the first commands or the responses
are garbled due to controller startup, this will not work.
Any yes, it is possible that this worked before, the GcodeAsyncDriver
will write the first two commands asynchronously, before
waiting for the first "ok". That may be sufficient to trip it.
The homing command has a special 1 minute timeout, so OpenPnP
will appear like "hanged".
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/24ff6657-3ddf-4b09-ae85-c6fa350423a3n%40googlegroups.com.
ma...@makr.zone
Hi Jim, Johannes, Clemens
I was able to confirm what Clemens said: RTS/CTS
does not work with TinyG.
However, it seems that XON/XOFF works (as Jim had it all the
time).
To test, I added Jim's CONNECT_COMMAND ten times.
I see the Writer Thread pause and then, after a proportionate
amount of responses, resume again, multiple times.
You need to have the $ex=1 set.
With the connect wait increased to 5000ms, I see no more issues.
I will adapt the Issues & Solutions for TinyG in the next
testing version.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyBgRCnoMZziBGWvs-cFSVHv1m0rOTvAukjf7byUXdOb%3DA%40mail.gmail.com.
ma...@makr.zone
Jim,
I just realized, you seem to be on an old OpenPnP version, and
backtracking it, I saw you actually mentioned that in the first
post.
So am I right to assume that all you changed is the TinyG
firmware? It worked before and now not?
That's really strange. Like Tony said, please send a new log, the
last one is still not at TRACE level (you must first set the level
and then retry homing).
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyBgRCnoMZziBGWvs-cFSVHv1m0rOTvAukjf7byUXdOb%3DA%40mail.gmail.com.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dfec6624-e230-de22-f270-8bd1e3d4759c%40makr.zone.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a7837d77-e0a5-d1bb-7fbd-cfe483600028%40makr.zone.
tony...@att.net
ma...@makr.zone
Hi Jim
First question: have you increased the connect wait time? Maybe having to increase that its related to ADC initialization. Maybe that's taking long(?).
Re your log: There are strange Error messages.
{"er":{"fb":440.21,"st":9,"msg":"File not open"}}
These are usually related to a ATMEGA bug in EEPROM writing, when then next command comes too quickly:
https://github.com/synthetos/TinyG/issues/148#issuecomment-166739904
But you should not have EEPROM writing, because these values should be unchanged from the last connect command, right? Can you explain this?
Also strange. Are you sure you don't want 8 microsteps?
2021-01-28 13:47:19.178 GcodeDriver TRACE:
[serial://COM3] << [1mi] m1 microsteps 10
[1,2,4,8]
2021-01-28 13:47:19.185 GcodeDriver TRACE: [serial://COM3]
<< *** WARNING *** Setting non-standard microstep value
2021-01-28 13:47:19.195 GcodeDriver TRACE: [serial://COM3]
<< tinyg [mm] ok> *** WARNING *** Setting non-standard
microstep value
2021-01-28 13:47:19.196 GcodeDriver DEBUG:
sendCommand(serial://COM3 $1mi=10, 10000) => [[1mi] m1
microsteps 10 [1,2,4,8], *** WARNING *** Setting
non-standard microstep
The actual homing problem is a vision failure:
2021-01-28 13:50:01.145 ReferenceFiducialLocator DEBUG: No matches found!
The question is: is the machine/camera at the right location?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyAnjAWUm4WW5L15YHLm3fYaEsF2mopD%3DKEymvzEMdLf_w%40mail.gmail.com.
ma...@makr.zone
Ok, two more things to try:
- If you want, you can test this version without ADC (i.e. it
has all the new OpenPnP commands but not the ADC, if that's what
you are actually after):
https://makr.zone/TinyG_Flash_no_ADC.7z - I noticed during my tests (and Clemens reported a similar
thing) that one needs to power-cycle the the TinyG after
changing the $ex option.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7f039f9-88da-fd2e-0b7b-6f5983f25f08%40makr.zone.
ma...@makr.zone
regarding this:
[1mi] m1 microsteps 10
[1,2,4,8]
*** WARNING *** Setting non-standard microstep value
There is this warning:
Note: Values other than 1,2,4 and 8 are accepted. This is to support some people that have crazily wired TInyG to other drivers (you know who you are) like those running 10x or 16x steps. If you are using the drivers on TInyG this will cause them to malfucntion, so please don't do this unless you are one of those hacker types that soldered up your TinyG.
Have you "crazily wired TinyG to other drivers"? ;-)
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7f039f9-88da-fd2e-0b7b-6f5983f25f08%40makr.zone.
Clemens Koller
> 2. I noticed during my tests (and Clemens reported a similar thing) that one needs to power-cycle the the TinyG after changing the $ex option.
This is propably not true in detail.
The "$ex=2" might be needed to unblock TinyG's RTS/CTS Flow Control.
The power-cycle might be needed to "clear" TinyG's brain which have led to this blocking communication as if RTS/CTS Flow Control would be off after propably serious other issues - as the "File not open error."
Currently, I recommend to bring TinyG back to life by:
* Use minicom or some other proper terminal program to communication with the UART.
* Feed TinyG it with some "\n" (Hit enter) to see if it answers with an "tinyg [mm] ok>".
* If it reacts, try to reset it "$defa=1" + "$ex=2" (+ maybe "$sv=0") + "\n" and power-cycle it afterwards.
* If it doesn't answer, retry with the reset button and retry.
* If it doesn't answer, retry with a power-cycle and retry.
I strongly recommend not doing this by OpenPnP as it will choke on a not answering UART and can crash and (maybe) even mess up your configuration and eat your cat!
Maybe the XON/XOFF Flow-Control is a more reliable way to communicate with TinyG. But I am not so sure about it.
There are rumours that if a EEPROM write (after some $commands) gets interrupted by some Interrupt (which can be from further UART communicaton), it might get haywire.
It seems like the most failsafe advice is to not emit any $commands at all during normal machine operation!
There are just too many *maybees* in here.
Regards,
Clemens
On 28/01/2021 21.57, ma...@makr.zone wrote:
> Ok, two more things to try:
>
> https://makr.zone/TinyG_Flash_no_ADC.7z <https://makr.zone/TinyG_Flash_no_ADC.7z>
> 2. I noticed during my tests (and Clemens reported a similar thing) that one needs to power-cycle the the TinyG after changing the $ex option.
> _Mark
>
>
> Am 28.01.2021 um 21:47 schrieb ma...@makr.zone:
>>
>> Hi Jim
>>
>> First question: have you increased the connect wait time? Maybe having to increase that its related to ADC initialization. Maybe that's taking long(?).
>>
>> Re your log: There are strange Error messages.
>>
>> {"er":{"fb":440.21,"st":9,"msg":"File not open"}}
>>
>> These are usually related to a ATMEGA bug in EEPROM writing, when then next command comes too quickly:
>>
>> But you should not have EEPROM writing, because these values should be unchanged from the last connect command, right? Can you explain this?
>>
>> Also strange. Are you sure you don't want 8 microsteps?
>>
>> 2021-01-28 13:47:19.178 GcodeDriver TRACE: [serial://COM3] << [1mi] m1 microsteps 10 [1,2,4,8]
>> 2021-01-28 13:47:19.185 GcodeDriver TRACE: [serial://COM3] << *** WARNING *** Setting non-standard microstep value
>> 2021-01-28 13:47:19.195 GcodeDriver TRACE: [serial://COM3] << tinyg [mm] ok> *** WARNING *** Setting non-standard microstep value
>> 2021-01-28 13:47:19.196 GcodeDriver DEBUG: sendCommand(serial://COM3 $1mi=10, 10000) => [[1mi] m1 microsteps 10 [1,2,4,8], *** WARNING *** Setting non-standard microstep
>>
>> The actual homing problem is a vision failure:
>>
>> 2021-01-28 13:50:01.145 ReferenceFiducialLocator DEBUG: No matches found!
>>
>> The question is: is the machine/camera at the right location?
>>
>> _Mark
>>
>> Am 28.01.2021 um 20:44 schrieb Jim Freeman:
>>
>>> Hi, Mark. I never had communications problems (with new firmware or old). What my problem is that when I home the machine it stops working. After starting Openpnp and turning on the machine I can jog around, move up/down in Z, things seem OK. When I try to home, it moves toward the home spot, sometimes I have to hit home again. When it actually gets to the limit switches and starts to look for the optical home the machine stops. It looks like it is going to sleep for a long time (looks like about 150 seconds exactly) then comes back to life. Then I can jog, turn off, turn on, .. But it never tries to optically home. Another thing is that the rate of rotation of the phi axis is much faster than earlier.
>>> Best, Jim
>>>
>>>
>>> On Thu, Jan 28, 2021 at 1:17 PM ma...@makr.zone <ma...@makr.zone> wrote:
>>>
>>> Hi Jim, Johannes, Clemens
>>>
>>> I was able to confirm what Clemens said: RTS/CTS does not work with TinyG.
>>>
>>> However, it seems that XON/XOFF works (as Jim had it all the time).
>>>
>>> To test, I added Jim's CONNECT_COMMAND ten times.
>>>
>>> I see the Writer Thread pause and then, after a proportionate amount of responses, resume again, multiple times.
>>>
>>> With the connect wait increased to 5000ms, I see no more issues.
>>>
>>> I will adapt the Issues & Solutions for TinyG in the next testing version.
>>>
>>> _Mark
>>>
>>> Am 28.01.2021 um 17:39 schrieb Jim Freeman:
>>>> I am attaching the log file, the TinyG response to $$, the machine.xml, my communication settings,
>>>>
>>>>
>>>>
>>>> image.png
>>>> image.png
>>>>
>>>> On Wed, Jan 27, 2021 at 3:24 PM tony...@att.net <mailto:tony...@att.net> <tony...@att.net <mailto:tony...@att.net>> wrote:
>>>>
>>>> Can you set your logging level to trace and post the entire log file?
>>>>
>>>> On Wednesday, January 27, 2021 at 3:15:30 PM UTC-6 james.edwa...@gmail.com <mailto:james.edwa...@gmail.com> wrote:
>>>>
>>>> Hi, Mark. As I said I can't home after updating the TinyG firmware: Here is some more information:
>>>>
>>>> My HOME command is :
>>>>
>>>> G28.2 X0 Y0 Z0 A0
>>>> G92 X0 Y0 Z0
>>>>
>>>> The TinyG result of M115 is
>>>>
>>>> > M115
>>>> _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.
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e0a37b82-7a00-4c88-a21e-901fe19d0e7dn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/e0a37b82-7a00-4c88-a21e-901fe19d0e7dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyBgRCnoMZziBGWvs-cFSVHv1m0rOTvAukjf7byUXdOb%3DA%40mail.gmail.com <https://groups.google.com/d/msgid/openpnp/CABRkqyBgRCnoMZziBGWvs-cFSVHv1m0rOTvAukjf7byUXdOb%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dfec6624-e230-de22-f270-8bd1e3d4759c%40makr.zone <https://groups.google.com/d/msgid/openpnp/dfec6624-e230-de22-f270-8bd1e3d4759c%40makr.zone?utm_medium=email&utm_source=footer>.
>>> --
>>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyAnjAWUm4WW5L15YHLm3fYaEsF2mopD%3DKEymvzEMdLf_w%40mail.gmail.com <https://groups.google.com/d/msgid/openpnp/CABRkqyAnjAWUm4WW5L15YHLm3fYaEsF2mopD%3DKEymvzEMdLf_w%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7f039f9-88da-fd2e-0b7b-6f5983f25f08%40makr.zone <https://groups.google.com/d/msgid/openpnp/d7f039f9-88da-fd2e-0b7b-6f5983f25f08%40makr.zone?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d96663ac-df22-2b21-483c-eac85838809f%40makr.zone <https://groups.google.com/d/msgid/openpnp/d96663ac-df22-2b21-483c-eac85838809f%40makr.zone?utm_medium=email&utm_source=footer>.
Clemens Koller
I've tried to send my machine.xml and initialization commands in a new thread, but the email doesn't seem to get it's way on the list.
What's wrong? I am subscribed to ope...@googlegroups.com and writing using Thunderbird.
Clemens
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e83ea40d-1cb3-4696-afdb-8d1dbc90fd71n%40googlegroups.com.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7f039f9-88da-fd2e-0b7b-6f5983f25f08%40makr.zone.
ma...@makr.zone
> It seems like the most failsafe advice is to not emit any $commands at all during normal machine operation!
I agree. As long as the commands don't change the EEPROM, they're
probably ok. Otherwise not. And yes, the GcodeAsyncDriver
definitely sends the next command while still waiting for
confirmation for the first, while this is not the case
with the GcodeDriver.
> Maybe the XON/XOFF Flow-Control is a more reliable way to communicate with TinyG. But I am not so sure about it.
With TinyG we can obviously be sure of nothing. :-(
Just so you know what I found: I duplicated Jim's CONNECT_COMMAND
ten times. This then showed clear errors with RTS/CTS. The writer
thread would just pump out commands without stopping. In the end commands were fused together.
2021-01-28 19:42:30.710
GcodeAsyncDriver$WriterThread TRACE: [serial://COM10] >>
$3tr=8
2021-01-28 19:42:30.711 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $ajm=25000
2021-01-28 19:42:30.712 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $avm=300000
2021-01-28 19:42:30.713 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4mi=8
2021-01-28 19:42:30.713 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4sa=0.9
2021-01-28 19:42:30.714 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4tr=160
2021-01-28 19:42:30.715 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $mt=300
2021-01-28 19:42:30.716 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zzb=2
2021-01-28 19:42:30.716 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $3po=1
2021-01-28 19:42:30.717 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zsx=3
2021-01-28 19:42:30.717 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zsn=0
2021-01-28 19:42:30.718 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> M115
2021-01-28 19:42:30.718 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:30.718 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $1pm=1
2021-01-28 19:42:30.719 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $2pm=1
2021-01-28 19:42:30.720 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $3pm=1
2021-01-28 19:42:30.720 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4pm=1
2021-01-28 19:42:30.721 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> G21M9
2021-01-28 19:42:30.745 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $1pm=0
2021-01-28 19:42:30.746 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [1pm] m1 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:42:30.761 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:30.788 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $2pm=0
2021-01-28 19:42:30.789 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [2pm] m2 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:42:30.803 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:30.829 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $3pm=0
2021-01-28 19:42:30.829 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [3pm] m3 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:42:30.845 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:30.871 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $4pm=0
2021-01-28 19:42:30.872 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [4pm] m4 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:42:30.887 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.005 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $mt=1000000000
2021-01-28 19:42:31.006 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [mt] motor idle timeout 1000000000.00
Sec
2021-01-28 19:42:31.006 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.006 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << G21G90G92X0Y0Z0A0M8M5
2021-01-28 19:42:31.006 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.007 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xjm=1000
2021-01-28 19:42:31.007 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xjm] x jerk maximum 1000
mm/min^3 * 1 million
2021-01-28 19:42:31.007 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.007 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xvm=10000
2021-01-28 19:42:31.008 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xvm] x velocity maximum 10000
mm/min
2021-01-28 19:42:31.008 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.008 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xsv=1000
2021-01-28 19:42:31.008 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xsv] x search velocity 1000
mm/min
2021-01-28 19:42:31.009 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.009
GcodeDriver$ReaderThread TRACE: [serial://COM10] <<
000000$mG90G92X0Y0Z0A0M8M5
2021-01-28 19:42:31.010 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] err: Invalid or malformed
command: 000000$mG90G92X0Y0Z0A0M8M5
2021-01-28 19:42:31.010 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xjm=1000
2021-01-28 19:42:31.010 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xjm] x jerk maximum 1000
mm/min^3 * 1 million
2021-01-28 19:42:31.010 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.011 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xvm=10000
2021-01-28 19:42:31.011 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xvm] x velocity maximum 10000
mm/min
2021-01-28 19:42:31.011 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.011 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xsv=1000
2021-01-28 19:42:31.012 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xsv] x search velocity 1000
mm/min
2021-01-28 19:42:31.012 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:42:31.012 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xsn=3
Then after setting it to Xon/Xoff (+ power cycle), it worked. The writer thread would stop and go hand over hand with the reader:
2021-01-28 19:43:38.092
GcodeAsyncDriver$WriterThread TRACE: [serial://COM10] >>
$ME
2021-01-28 19:43:38.092 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $1pm=0
2021-01-28 19:43:38.093 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $2pm=0
2021-01-28 19:43:38.093 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $3pm=0
2021-01-28 19:43:38.093 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4pm=0
2021-01-28 19:43:38.094 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $mt=1000000000
2021-01-28 19:43:38.094 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> G21G90G92X0Y0Z0A0M8M5
2021-01-28 19:43:38.094 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $xjm=1000
2021-01-28 19:43:38.094 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $xvm=10000
2021-01-28 19:43:38.094 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $xsv=1000
2021-01-28 19:43:38.095 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $xsn=3
2021-01-28 19:43:38.095 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $xjh=1000
2021-01-28 19:43:38.095 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $xsx=2
2021-01-28 19:43:38.095 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $1mi=10
2021-01-28 19:43:38.095 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $1sa=0.9
2021-01-28 19:43:38.095 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $1tr=39.982
2021-01-28 19:43:38.096 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $yjm=1000
2021-01-28 19:43:38.096 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $yvm=10000
2021-01-28 19:43:38.096 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $ysn=3
2021-01-28 19:43:38.096 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $ysx=2
2021-01-28 19:43:38.097 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $yjh=1000
2021-01-28 19:43:38.097 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $ysv=1000
2021-01-28 19:43:38.097 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $2mi=10
2021-01-28 19:43:38.097 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $2sa=0.9
2021-01-28 19:43:38.098 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $2tr=39.97
2021-01-28 19:43:38.212 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [sv] status report verbosity 2
[0=off,1=filtered,2=verbose]
2021-01-28 19:43:38.212 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.213 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $ME
2021-01-28 19:43:38.213 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $ME
2021-01-28 19:43:38.213 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.213 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $1pm=0
2021-01-28 19:43:38.213 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [1pm] m1 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:43:38.213 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.213 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $2pm=0
2021-01-28 19:43:38.214 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [2pm] m2 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:43:38.214 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.214 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $3pm=0
2021-01-28 19:43:38.215 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [3pm] m3 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:43:38.215 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.215 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $4pm=0
2021-01-28 19:43:38.215 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [4pm] m4 power management 0
[0=disabled,1=always on,2=in cycle,3=when moving]
2021-01-28 19:43:38.216 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.216 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $mt=1000000000
2021-01-28 19:43:38.216 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [mt] motor idle timeout 1000000000.00
Sec
2021-01-28 19:43:38.216 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.216 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << G21G90G92X0Y0Z0A0M8M5
2021-01-28 19:43:38.216 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.216 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xjm=1000
2021-01-28 19:43:38.217 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xjm] x jerk maximum 1000
mm/min^3 * 1 million
2021-01-28 19:43:38.217 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.217 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xvm=10000
2021-01-28 19:43:38.217 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xvm] x velocity maximum 10000
mm/min
2021-01-28 19:43:38.217 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.217 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xsv=1000
2021-01-28 19:43:38.218 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xsv] x search velocity 1000
mm/min
2021-01-28 19:43:38.218 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.218 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xsn=3
2021-01-28 19:43:38.219 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xsn] x switch min 3
[0=off,1=homing,2=limit,3=limit+homing]
2021-01-28 19:43:38.219 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.219 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xjh=1000
2021-01-28 19:43:38.219 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xjh] x jerk homing 1000
mm/min^3 * 1 million
2021-01-28 19:43:38.219 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.219 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $xsx=2
2021-01-28 19:43:38.220 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [xsx] x switch max 2
[0=off,1=homing,2=limit,3=limit+homing]
2021-01-28 19:43:38.220 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.220 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $1mi=10
2021-01-28 19:43:38.221 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [1mi] m1 microsteps 10
[1,2,4,8]
2021-01-28 19:43:38.221 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << *** WARNING *** Setting non-standard
microstep value
2021-01-28 19:43:38.221 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok> *** WARNING ***
Setting non-standard microstep value
2021-01-28 19:43:38.221 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $1sa=0.9
2021-01-28 19:43:38.222 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [1sa] m1 step angle
0.900 deg
2021-01-28 19:43:38.229 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.278 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zjm=200
2021-01-28 19:43:38.279 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zvm=1000
2021-01-28 19:43:38.279 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zjh=500
2021-01-28 19:43:38.280 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zsv=1000
2021-01-28 19:43:38.282 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $xfr=10000
2021-01-28 19:43:38.283 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $yfr=10000
2021-01-28 19:43:38.283 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zfr=1000
2021-01-28 19:43:38.285 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $afr=300000
2021-01-28 19:43:38.285 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $3mi=8
2021-01-28 19:43:38.285 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $3sa=1.8
2021-01-28 19:43:38.286 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $3tr=8
2021-01-28 19:43:38.287 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $ajm=25000
2021-01-28 19:43:38.288 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $avm=300000
2021-01-28 19:43:38.289 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4mi=8
2021-01-28 19:43:38.290 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4sa=0.9
2021-01-28 19:43:38.290 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $4tr=160
2021-01-28 19:43:38.291 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $mt=300
2021-01-28 19:43:38.291 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zzb=2
2021-01-28 19:43:38.292 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $3po=1
2021-01-28 19:43:38.293 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zsx=3
2021-01-28 19:43:38.294 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $zsn=0
2021-01-28 19:43:38.294 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> M115
2021-01-28 19:43:38.294 GcodeAsyncDriver$WriterThread TRACE:
[serial://COM10] >> $1pm=1
2021-01-28 19:43:38.424 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $1tr=39.982
2021-01-28 19:43:38.424 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [1tr] m1 travel per revolution
39.9820 mm
2021-01-28 19:43:38.424 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.424 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $yjm=1000
2021-01-28 19:43:38.425 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [yjm] y jerk maximum 1000
mm/min^3 * 1 million
2021-01-28 19:43:38.425 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.425 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $yvm=10000
2021-01-28 19:43:38.425 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [yvm] y velocity maximum 10000
mm/min
2021-01-28 19:43:38.426 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.426 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $ysn=3
2021-01-28 19:43:38.426 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [ysn] y switch min 3
[0=off,1=homing,2=limit,3=limit+homing]
2021-01-28 19:43:38.426 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
2021-01-28 19:43:38.426 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << $ysx=2
2021-01-28 19:43:38.427 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << [ysx] y switch max 2
[0=off,1=homing,2=limit,3=limit+homing]
2021-01-28 19:43:38.427 GcodeDriver$ReaderThread TRACE:
[serial://COM10] << tinyg [mm] ok>
_Mark
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/833d5342-afd8-40dd-c94d-bbd9e597e6e9%40makr.zone.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/833d5342-afd8-40dd-c94d-bbd9e597e6e9%40makr.zone.
ma...@makr.zone
Somehow it winds up the A axis to -1440° at a 600°/min rate, so
that explains the duration.
Why do you G92 at all?
If there is a reason, (I don't think so) perhaps you'd need to
add A0 to it?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CABRkqyA8d%3D8COdSMK64F87FnACZpoBTP9bp5-%3DRapG2t4k-tsg%40mail.gmail.com.
johanne...@formann.de
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/833d5342-afd8-40dd-c94d-bbd9e597e6e9%40makr.zone.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d288e9c4-7594-0dda-44c7-feeb3754349c%40makr.zone.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e928829-b0ff-4a7e-8201-69b2b3945946n%40googlegroups.com.
ma...@makr.zone
Do you guys know what TinyG version you had before?
I guess the maximum travel at 150mm is too low. Maybe that
setting is new in the master version
I took as the basis:
[xtm] x travel maximum 150.000 mm
Maybe it didn't exist in your version.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e928829-b0ff-4a7e-8201-69b2b3945946n%40googlegroups.com.
tony...@att.net
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/528ad303-6f0a-1451-4ee6-37ba00f2737c%40makr.zone.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6f6f4ac7-4505-43a4-a5a4-a516a8c36a83n%40googlegroups.com.
ma...@makr.zone
"Some of the command definitions have been changed from 0.92 and earlier. These are labeled as [$xNN 0.92] where this occurs."
"$xTM Travel Maximum. [$xTS 0.92] Defines the maximum extent of travel in that axis. This is currently only used during homing but will also be used for soft limits when that feature is implemented."
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/528ad303-6f0a-1451-4ee6-37ba00f2737c%40makr.zone.
Jim Freeman
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/6f6f4ac7-4505-43a4-a5a4-a516a8c36a83n%40googlegroups.com.
johanne...@formann.de
$ee=1 ; echo command
$mt=3600 ; 1h timeout
$ME ; enable stepper motor
G21 G90 G92 X0 Y0 Z0 A0 M8 M4
; mapping of the axis
$1ma=0
$2ma=1
$3ma=2
$4ma=3
; x
$1pm=2 ; motor energized until $mt timeout after last move
$1sa=0.900 ; degree per full step
$1mi=8 ; microsteps
$1tr=39.983 ; Travel per revolution
$xjm=1450 ; max jerk
$xvm=21000 ; max velocity
$xfr=21000 ; max feedrate
$xsn=3 ; minimum switch mode limit & home
$xsx=2 ; maximum switch mode limit only
$xjh=2500 ; jerk homing
$xsv=1700 ; search velocity
$xtm=590 ; maximum travel on that axis
; y
$2pm=2 ; motor energized until $mt timeout after last move
$2sa=0.900 ; degree per full step
$2mi=8 ; microsteps
$2tr=39.900 ; Travel per revolution
$yjm=1400 ; max jerk
$yvm=27000 ; max velocity
$yfr=27000 ; max feedrate
$ysn=3 ; minimum switch mode limit & home
$ysx=2 ; maximum switch mode limit only
$yjh=2500 ; jerk homing
$ysv=1750 ; search velocity
$ytm=400 ; maximum travel on that axis
; z
$3pm=2 ; motor energized until $mt timeout after last move
$3sa=1.800 ; degree per full step
$3mi=8 ; microsteps
$3tr=8.0000 ; Travel per revolution
$3po=1 ; invert direction
$zjm=2300 ; max jerk
$zvm=8000 ; max velocity
$zfr=8000 ; max feedrate
$zsn=0 ; minimum switch mode limit & home
$zsx=3 ; maximum switch mode limit only
$zjh=2000 ; jerk homing
$zsv=1500 ; search velocity
$ztm=50 ; maximum travel on that axis
; a
$4pm=2 ; motor energized until $mt timeout after last move
$4sa=0.900 ; degree per full step
$4mi=8 ; microsteps
$4tr=160.00 ; Travel per revolution
$ajm=600 ; max jerk
$avm=40000 ; max velocity
$afr=40000 ; max feedrate
$asn=0 ; minimum switch mode limit & home
$asx=0 ; maximum switch mode limit only
G28.3 A0
johanne...@formann.de
tony...@att.net
ma...@makr.zone
Jerk in OpenPnP is mm/s³ in TinyG it is km/min³
So the factor is 1'000'000/60/60/60 = 4.63
> Second: my Rotation problem was a mising $aam=1
Any idea how the $aam or $xmt etc. got lost on the foirmware
update?
Maybe the TinyG EEPROM persistence isn't that stable after all
and Clemens was right.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3750ca51-fb80-415b-b3fb-99c9381a794dn%40googlegroups.com.
Clemens Koller
On 29/01/2021 07.55, ma...@makr.zone wrote:
> Any idea how the $aam or $xmt etc. got lost on the foirmware update?
>
> Maybe the TinyG EEPROM persistence isn't that stable after all and Clemens was right.
I recommend writing all the $commands configuration _slowly_ to TinyG _before_ starting OpenPnP.
I strongly suggest to _not_ write any $commands during a regular machine PnP run.
In case OpenPnP crashes (which it does) or if you run into an end-switch and have to recover from
scratch and hit the Reset-Buttin on the TinyG, it will have the $command stored in EEPROM already.
So a reset doesn't then reset to assumable "good" $commands (or $settings if you like).
It seems like the communication issues are calming down once I switched to XON/XOFF Flow-Control.
Because the GcodeAsyncDriver is pushing the communication much harder, these issues came to surface.
I'll post my currently known good configuration soon.
Regards,
Clemens
On 29/01/2021 07.55, ma...@makr.zone wrote:
> Jerk in OpenPnP is mm/s³ in TinyG it is km/min³
>
> So the factor is 1'000'000/60/60/60 = 4.63
>
>>
>> https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions <https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions>
>> Please send the machine.xml
>>
>> _Mark
>>
>> Am 28.01.2021 um 02:53 schrieb johanne...@formann.de:
>>> Took "a bit" more time.
>>> Some experiences:
>>> - visual homing does not work anymore
>>> - needed to press home three times to get homing
>>> - sometimes commands timeout
>>> - A axis had to renamed manually from E (rotation)
>>> - rotation is somewhat off (instead 1° about 300°)
>>> - Z does not work
>>>
>>> on the bright side: speed control seems to work.
>>> Has someone a working configuration that I can use for "inspiration".
>>>
>>> greetings
>>> Johannes
>>>
>>> johanne...@formann.de schrieb am Dienstag, 26. Januar 2021 um 09:08:21 UTC+1:
>>>
>>> ma...@makr.zone schrieb am Dienstag, 26. Januar 2021 um 08:21:55 UTC+1:
>>>
>>> If you used git to track it, I see no problem to merge the new test branch back into your branch.
>>>
>>> There were few feeder related changes. I remember only two:
>>>
>>> That sound doable, I guess I try it in the afternoon.
>>>
>>> Are you planning to make a PR?
>>>
>>> Yes, wanted to populate some pcbs before (make sure it works reliable, maybe optimize some details), but a PR is planed.
>>>
>>> Johannes
>>>
>>> --
>>> 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.
>> --
>> 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.
>>
>> --
>> 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.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3750ca51-fb80-415b-b3fb-99c9381a794dn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/3750ca51-fb80-415b-b3fb-99c9381a794dn%40googlegroups.com?utm_medium=email&utm_source=footer>.
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/083b28bd-d365-2959-2fdf-636622f6c0ab%40makr.zone <https://groups.google.com/d/msgid/openpnp/083b28bd-d365-2959-2fdf-636622f6c0ab%40makr.zone?utm_medium=email&utm_source=footer>.