cmcgrath5035

These look OK.
Just one more suggestion; if you set $2po=0 and $3po=1, any change in action?

It does seem that the M3 driver is flaky, either intermittent connection or bad device.

No, Limit switches affect axes, not Motors (but, of course motors are assigned to axes).
So the Y axis has one motor working and one not – does not sound like a limit switch issue.

Your ohms look OK – I was checking that windings were connected to the board.

Are you sure $2mi and $3mi are the same (probably both = 8)?

Does this apply to Chilipeppr activity as well as CoolTerm

Should clarify the reset was a hardware reset using the button on the board,

As you may know, when SPJS first connects to tinyG, it sends a number of command queries to get synced up with tinyG. You can see this in the CP Serial port Console window (lower left of GUI).
A number of commands are queued up, then get checkmark as they execute. One of those commands will return $fb and that will be displayed in the TinyG Widget.

You should not have to manually reset tinyG after starting up CP. The fact that SPJS sees and is able to connect to the ftdi device seems to indicate that at least the USB side of ftdi is working OK.

If you HAVE TO reset tinyG to get any response in CP, that would seem to support my theory that the path from ftdi into the Xmega has an issue.
CP may be able to use the autonomous status broadcast (that you see in CoolTerm) to populate the $fb field, but will appear hung, as you report, if the other start up commands are not being heard and responded to.

II understand you are flashing via ISP, I’m not much help there.
Unclear if there are operational side effects of bootloader nor running properly.

Did you send a rest command (ctl-x) or hit the rest button to get that response in Coolterm?
The parameters reported , “fv”:0.970,”fb”:440.14,”hp”:1,”hv”:8,”id”:”5U1316-KLZ”, are from the parameter set , but may be read from FLASH rather than EEPROM.

I do know that when you use the bootloader to update your tinyG FW (e.g. 380.xy to 440.yz), the EEPROM gets rewritten with the new FW’s set of defaults, I assumed on first boot of the new FW.

I have no experience with the MKII method of programming.

Do you still not get the flashing LED when you manually reboot to tinyG? That of course is not correct behavior.

When you say that Chilipeppr identifies the board FW, are you doing a manual reset of tinyG or is the CP requesting the board info?

I’m sort of wondering if the receive path of the on-board ftdi device is bad, but transmit is good

• This reply was modified 9 years, 3 months ago by cmcgrath5035.

Another defa=1 might help, but this does not feel like that sort of problem.
Does not sound like reflash either.

If Motor 3 is disable then y moves

If Motor 2 is disabled, does Motor 3 work?
Are they fighting each other?

Can you post your most recent $$?

If I can figure out how to, I’ll move this thread to Feature Request.

Interesting idea, more of an application layer concept than motion control focus, let’s see what others think.