Forum Replies Created
-
Failures of this sort are reported very infrequently here, but of course stuff happens. Good show, resoldering devices is not an easy task but the FTDI device is one of the easier ones, I suppose.
For someone drawn here by Search Engines, a few tid bits.
For the tinyG application, the FTDI device is powered by the tinyG 3.3V logic power bus, not power available from the USB cable via the host connection.
Schematic page is here: https://github.com/synthetos/TinyG/blob/master/hardware/v8schematics/v8h/tinyGv8h%20-%20schematic%20page1.pdf
The FTDI device should be considered ‘hardware’ in this application, its operation is not affected by the sanity or running status of tinyG FW. The device converts the serial bit stream delivered over the USB bus to a logic level serial input to the UART function on the Atmel microcontroller which is running tinyG FW.
From the schematic, you can see that the Tx and Rx activity LEDs are controlled by the FTDI device, not tinyG FW running on the Atmex.What caused this event is anyone’s guess, could simply be a device failure, could have been a cold solder issue with the original device, could be a foreign voltage on the USB bus, or numerous other causes.
These are some random thoughts.
Relay – Make sure that any relay coil you connect has a flyback diode included. Most relays intended for logic applications do – otherwise the port pin plays flyback and often the reverse bias results in death.
Power supply switch teads- It would be informative to know what voltage you measure on the two leads when the shorting wire is removed. I’ll guess one is GND, since you measure 0 volts, but the other could be Line in (120/240) AC, or something DC, if there is some sort of standby that is always on.
8 – When I see the number 8, I immediately wonder if microstepping is not working but tinyG calculations assume that it is. Microstepping is communicated between the ATxmega and the Driver device by two port pins. Perhaps those two port pins fried ? All the tinyGV8 schematic pages are here https://github.com/synthetos/TinyG/tree/master/hardware/v8schematics/v8h
Atmel Studio – I defer to Zootalaws, I have never used it. My impression was/is that useful debugging at this level might require an AtmelICE in addition to the working (running) tinyG
GND – Be a bit cautious assuming that all Power supply grounds are the same potential. I have to assume that the relatively compact 500W spindle supply is a buck converter(transformerless). I’ll guess that your tinyG and Stepper supply is also a buck supply, most are. Exercise caution (e.g. use relay or opto-isolator) to keep tinyG GND and Logic isolated from other power supplies.
FW Upgrade – https://github.com/synthetos/TinyG/wiki/TinyG-TG-Updater-App works sometimes, not others. Most all the various updaters end up calling a local copy of AVRDUDE. My read of the thread overall says that you knowingly had, before this spindle event, customized your parameter set to work your unique machine, and that all moved and worked as you expected.
If either $defa=1 or a FW reload was successful, then your parameter set would have returned to the defaults and you would have to reload you unique set.
It is not clear to me that you had to reload you parameters.Parameter set – What triggered me to ask was seeing
[1tr] m1 travel per revolution 2.0050 in but
[2tr] m2 travel per revolution 2.3575 in as well as [3tr].
It is unusual, but clearly possible, for the X and Y drivetrains to be different.
Also, $1tr = 50.927 is a unique (unusual) number in this space, but easily explained when you say your are cannibalizing old gearUnits – Are you using inch, rather than mm, for a specific reason?
If not, I suggest you convert to mm. tinyG uses mm in native calculations. Some Gcode generated in inch does not work, related, I think, to loss of precision in multiple mm to inch to mm conversions done on the 8bit
ATxmega.
