fried board?

[six.two.eight]

tiny g was working perfectly, then when preparing a new pcb to mill i bumped something and the main ground wire came loose (while powered) and came into contact with the capacitor that lied between the main power input and the fan connection. contact was made (heard a pop and visually saw the spark). now the only thing that *seems* to have been affected is noise in the line for z homing/probing. when trying to do so it acts as if the endmill is already in contact with the copperclad and the z axis doesn’t even try and move. i get this is because of noise but is there anything i can do about it or do i just have to get a new one?

[cmcgrath5035]

Ouch
Unfortunately, I believe that the probing cycle is logically tied to the Z min port.
I am going to assume you have run the probing operation before, so know how to do it, it just does not work now.
Do you use other ports for limit/homing?
You might be able to recompile tinyG FW, moving (swapping) Zmn for another physical port. It would be good to know that the other port was functioning properly before heading down this path.
You up for some medium duty FW work?

[six.two.eight]

ummmm i’ve never done any fw work before… i wouldn’t know where to begin… tho the universe handed me this problem so maybe it’s time to learn lol.

yes, i’ve been probing for a bit now. funny thing is that i just ordered (and received today actually) switches for the rest of the axis so i’m not using any others-but was planning to. lol. i guess first step is to wire wire it all up to make sure the other ports are working.

i may just go ahead and get another board as i’m behind in a few projects i need to catch up on. i need to print out some brackets for the switches too… in the meantime whats the fw work look like?

[cmcgrath5035]

An upfront caveat – I have not done this myself in tinyG space, I have built several custom versions of G2core. The tool chains are similar, but different. There is more documentation around the build process for G2core.

To scope your appetite for this, start by familiarizing yourself with the tinyG wiki at https://github.com/synthetos/TinyG/wiki and with the tinyG repository at https://github.com/synthetos/TinyG

The wiki has several items related to the build process, the code base and some descriptions of the probing process.

The basic steps
1. Clone the tinyG repository onto you local machine
2. Set up the build environment
3. Learn to run the build environment, verify that you can compile the current Master branch on you computer and build a 440.20.hex file that is identical to the precompiled hex file downloadable from Synthetos.
4. Review the code base, identify how the Zmin switch is handled and how it gets connected to a physical pin on the XMega device.
5 Identify an available alternate pin that you don’t need, modify code or more likely a header file to swap Zmn with the available pin. For example, if you forego Z axis homing, you could logically swap Zmn and Zmx.
6. Modify your code base and build the modified .hex file.

What PC environment are you Familiar with/ do you use? Win/Mac/Linux?
The build details will be a little different with each.

For a taste of what it looks like, review this thread: https://www.synthetos.com/topics/alternative-to-pwm-spindle/

I don’t think I would head down this path if you can’t verify basic usability of the other ports. Given the rather uncontrolled nature of your wiring disconnect, whatever killed Zmn might have killed other pins. Worse yet, there could be intermittent damage.

You are likely better off to get back into production with a new tinyG and use this as a learning for the future project that might yield a usable backup. But that is your decision.

[Author]

Posts