cmcgrath5035

I

have tried powering down the tinyG while a plink connection is active. As soon as the blue pwr LED goes out on the tinyG, the RPi posts a “Bad file descriptor” msg implying that their connection is dependent upon tinyG being powered.

I would expect this. Removing Vmot (24V) also removes power from the FTDI device that terminates USB connection. The FTDI device is not powered from the USB bus.

Nothing. It is as if the reset button is inoperable. Blue LED does not even flicker. RPi/plink stay happy although when you look at the device log you can see it disconnected and reconnected.

Per the schematic, Blue LED simply says 3.3v supply is on.
The response to pushing the reset button would be under control of the bootloader; I agree with you that It sounds like bootloader is gone.

It is possible that what you report is simply clean flash. (program storage). You might be able to reflash the ATxmega if you had an atmel ICE.
Or you could try returning the board to Synthetos for a courtesy re-flash.
I’m not optimistic, you unit sounds deader than most, but might be worth a try

I don’t think you could do this via TxRx interface. To load new code via that interface you need to be able to trigger the downloader firmware in the ATxmega.
An ICE can talk directly to memory sub section on a somewhat sane device.

Is there a specific version of UGS that works with 100.xx?

I don’t recall seeing traffic on the UGS question, perhaps someone will chime in.
Does UGS have a “speak JSON” option?
G2core defaults to JSON for almost everything.
You can modify that behavior by modifying $ej parameter

A few ideas, you have many things going on here (maybe).

The current builds of G2core you could try can be found here:
https://github.com/synthetos/g2/releases

g2core-gShield-101.02.bin is the most up to date prebuilt binary for DUE/gshield.

Read the G2core wiki.
As of release 100.xx, G2core reverted to exposing only one USB divice when connecting an transitioned to using Line Mode protocol.

If you continue to see the “unknown “TinyG v2” device” on startup, you might have a driver issue with Win7(64 bit).

Good news and good luck with your project.

Caution – “optos must have built in weak pullups, but no schematic so just a guess” — Pullups to what voltage??
If any tinyG in or out sees more than 3.3V, weak or not, death could be imminent.

I would verify first that the opto leads are completely isolated from any potentially large voltages.

It is likely that the tinyG outs can sink more current than it can source, but there is not easy logical(software) way to flip the “on” level for these outputs

Have a look at https://github.com/synthetos/g2/wiki/G2core-on-DUE—External-Interfaces
A single MOSFET switch such as shown in the “External Interface Suggestions” would work for your need.
the DUE and tinyG device hardwrae is similar, 3.3V logic

Thanks for the heads up about 101.02 release, I missed that.

There is no DUE/gShield build yet either, not sure why.
As we already know, the current list of assigned pins does not leave much room, so I feel safe in saying that the answer will be decide what you don’t need with the current mapping and use Motate to create your own.

Keep your eyes out for an update, I have asked the devs for some guidance.

I read your query to say you did not want to re-home.

Rehoming would of course be most accurate, but does take time and would still require you to figure out from where to restart your Gcode job.
And all of this discussion probably dictates that you generate Gcode in absolute mode, rather than relative mode for best results.

If you were to re-home, then proceed to run absolute mode Gcode, then offsets should not be required.

What sort of jobs are you running?
Small errors in a long 2.5D job would probably not be obvious, but restarting a fine pitch PWB milling job may not work so well.

I don’t use homing, so can only read the wiki and add comments from others.

Here are suggested parameters for a Belt MAchine (SHO2) with
a screw Z axis.

[xjm] x jerk maximum 5000 mm/min^3 * 1 million
[xjh] x jerk homing 10000 mm/min^3 * 1 million
[xsv] x search velocity 3000 mm/min
[xlv] x latch velocity 100 mm/min
[xlb] x latch backoff 20.000 mm
[xzb] x zero backoff 1.000 mm
[yjm] y jerk maximum 5000 mm/min^3 * 1 million
[yjh] y jerk homing 10000 mm/min^3 * 1 million
[ysv] y search velocity 3000 mm/min
[ylv] y latch velocity 100 mm/min
[ylb] y latch backoff 20.000 mm
[yzb] y zero backoff 1.000 mm
[zjm] z jerk maximum 50 mm/min^3 * 1 million
[zjh] z jerk homing 1000 mm/min^3 * 1 million
[zsv] z search velocity 3000 mm/min
[zlv] z latch velocity 100 mm/min
[zlb] z latch backoff 20.000 mm
[zzb] z zero backoff 1.000 mm

High jerk will be more aggressive in changing velocity, from low to high or high to low. If you have a low mass spindle, Jerk could be higher.