Topic: Step, Dir, Enable Breakout

This topic has 22 replies, 5 voices, and was last updated 8 years ago by Keith-W.

Viewing 15 posts - 1 through 15 (of 23 total)

1 2 →

Author

Posts
September 25, 2013 at 9:07 pm #4609

InPhase
Member

I am still having a little trouble from the board. Nothing major, I understand it’s being worked on and I’m here for the ride. But until the firmware gets working better and tgFX is up, I was thinking of alternative ways to drive my machine using the board. I am hoping Alden can chime in.

I notice that the step, direction and enable are broken out on the v8 board through a set of vias for each axis. Understandably this is intended to allow other drivers to receive signals from the board. But the labeling on the wiring diagram seems to indicate that the outputs to the vias and the input of the 8818’s are electrically continuous. SO….

Could I bring a signal INTO the vias and drive the 8818’s from an external interface without damaging U1? I was picturing a parallel port interface controlled by Mach3, piped through some TI 7414 Schmitt inverters (’cause I have a bunch of them) and into the vias on the Tiny G. Obviously this wouldn’t be supported by Synthetos, but would it work?

Thanks.

September 26, 2013 at 4:37 pm #4621

alden
Member

I think it’s dicey. Those signals are driven by output lines on the Xmega. These are 3.3v outputs and won’t be happy about 5v, so avoid that. Electrically you will see 2 output stages fighting with each other, so the Mach3-sourced signals will have to win (drive the Xmega lines low).

One possibility would be to hack the Xmega code so those lines are inputs – i.e. disconnected. THat should work better.

It’s really up to you if you want to try it. If so be sure not to send more than about 3v into the board.

September 26, 2013 at 5:21 pm #4623

Riley
Keymaster

I would avoid this. tgFX is not confirmed to be working with 380.05. I created a Win32 bin (build 2072) and posted it last night.

I would not risk it 🙂

Riley

September 27, 2013 at 9:27 am #4625
InPhase
Member
You guys are great. I don’t want to pursue this unless I absolutely have to. I drew a circuit diagram last night and gathered the parts I will need to put it together, but I want to give 380.06 a shot and see if it corrects the minor problems I’m having with the dev branch and the major problems I had with 380.05.

So, simply disabling the motors ($md) won’t be sufficient for backfeeding the drivers with an external signal? My adapter circuit design includes provisions to limit the signal voltage from the PC to 3.3 V. Basically, the parallel port delivers power and signal to a couple of Schmitt trigger hex inverters, which then switch transistors powered by the 3.3 V output of the TG to deliver signals to the 8818’s through the vias on the board.

BUT… if the $md command isn’t going to cut it, then I’m stuck because I have 0 knowledge of how to make the appropriate changes to the code. I’m praying that the 380.06 edge and new tgFX build do the trick.

BTW Alden, were you able to reproduce the carnage I had in the gcode I sent you?
- This reply was modified 11 years, 1 month ago by InPhase.
September 27, 2013 at 9:40 am #4627

alden
Member

Let’s see how 380.06 does for you. If it doesn’t work I’d like to get details because that needs to be chased down if there are any errors.

Separately, I can get you a hex file with the outputs disabled if you want to try that.

September 27, 2013 at 9:41 am #4628
alden
Member
By the way, I got some of those Automation Technology 425 oz-in NEMA 23 motors in you found. Really nice. Here’s a video:

http://www.flickr.com/photos/rileyporter/9959403684
- This reply was modified 11 years, 1 month ago by alden.
- This reply was modified 11 years, 1 month ago by alden.
- This reply was modified 11 years, 1 month ago by alden.
- This reply was modified 11 years, 1 month ago by alden.
- This reply was modified 11 years, 1 month ago by alden.
September 27, 2013 at 9:47 am #4634

alden
Member

Regarding the Gcode file, I have not had a chance to get to my bench long enough due to travel demands. This weekend for sure.

September 27, 2013 at 12:23 pm #4636

InPhase
Member

OK. I tested 380.06 and it fails at exactly the same spot the master and previous edge build do. The only firmware that even comes close to working for me is the dev. And it works pretty good but just misses a couple of spots that leave extra hand work to do.

So, if you don’t mind, shoot me that hex file and I will build my adapter circuit and use mach3 until a firmware is released that works better. EMAIL: frontdesk@alabamainphase(dot)com

Thanks again.

September 29, 2013 at 7:26 pm #4649

InPhase
Member

So, I managed to slog my way through making the changes to system.h and making a new hex file. What an experience that was. Anyway, the motor outputs don’t seem to be floating. Motor 1 is still enabled all the time. And the rest of them seem to be pulled low.

Short of cutting the traces on the board or buying something else to drive my machine, what else can I do, why hasn’t the system.h change been effective?

September 30, 2013 at 10:32 pm #4658

Riley
Keymaster

InPhase,

I am not sure which way is up in this post to be honest. Why are you changing code? Because 380.06 is not working with tgFX?

I ran that gcode you sent alden (I had to remove % at the top and bottom of the file as this char is reserved for TinyG stuff).

Its still running now. But things look good. Also as far at the “mach3” adapter we stated that this was “dicey” and we would avoid that. Was this done? I really am not sure what you are troubleshooting or what you want to accomplish also I am not sure what the state of your TinyG is at the moment :).

riley

September 30, 2013 at 10:51 pm #4659

InPhase
Member

I did not build the adapter. I changed the code so that I could leave the outputs from the xmega to the drivers floating in case I did decide to make the adapter. What I found out was that stray capacitance would tend to cause the enable lead on motor 1 to fluctuate since it was floating. I was just too stupid to realize it when I made that post.

When I run that gcode, about 2/3 of the way through using any firmware but the dev branch, the little left hand tail of the “F” is the first sign of trouble. It cuts the outline of it at the very beginning, but towards the end, after it completes the ellipse, it will go back to “F” and plow through that tail and proceed to just eat away everything it has done. I posted picture of it in another thread.

It happens at the exact same spot using the edge and master branches, even 380.06. The dev works well, but it doesn’t work with tgFX, so it’s kind of a damned if you do, damned if you don’t scenario. That is, the master and edge work with tgFX, but don’t run the gcode well. And the dev runs the code ok, but doesn’t work with tgFX!

October 1, 2013 at 12:01 pm #4667

Riley
Keymaster

@InPhase,

UPFRONT WHAT TO DO:
I need you to load 380.06 and use this tgFX.
https://www.dropbox.com/sh/huiupgemipv8f4q/X2l_1EH-gx

The question I really need to understand is what are you trying to do?
I think you are trying to run the Ford file with tgFX and master and that fails?

You say it fails at the very same spot every time? Can you mark the line number its on (bottom label of tgFX “Block Number”)
I did that very thing as the images above demonstrate.

Here is another shot..

Here is it finished.. Note my travel max was off a bit.

So in my screen shots where was the issue? I am running 380.06 with tgFX build 2077. Can you try to do the very same test I did? Run the file with the motors inhibited or disconnected and see if your tgFX preview drawing looks like mine.

From what I have ran there is nothing wrong at all with the firmware or tgFX. Are you using tgFX build 2077? Also, have you tried sending the file with coolterm? Do you get the same results?

Also, YOU SHOULD NEVER NEVER NEVER us dev branch. This is dangerous! A lot of the time Alden has stuff that just starts motors moving on reset. Stuff like that on live machines = loss of fingers etc.

Riley

October 1, 2013 at 3:07 pm #4670

InPhase
Member

Well, I tell you, I have had the most amazing luck. Last night I heard one tiny rumble of thunder and woke this morning to find my blueray player and cable box dead as well as the surge protector they are plugged into. And out in the shop, the computer and TinyG are smoked too! LOL! But I’m an optimist.

To answer your questions, I first spot trouble around line 6800. There is a triangular island of material beneath the “r” and “d” that the machine rapids over to clear away. It doesn’t completely get it all and this is the first sign. Soon afterwards it moves over to begin finishing the letter outline and it just plows right into the tail coming off the left side of the letter “F” and it only gets worse from there. Coolterm does the same.

You won’t be able to see this with the motors inhibited because the screen simulation is fine. But the actual workpiece is pure carnage. As far as using dev, I understood the risk. I bought a $129 driver that wouldn’t run in any way but dev, so I took a chance. Now here I sit, with no driver and no computer to push it with LOL!

I have another computer I can set up, I just need to get another board now.

October 1, 2013 at 3:09 pm #4671

InPhase
Member

If you want to donate one, I’d be happy to test it out for you LOL!!!

October 1, 2013 at 6:40 pm #4674

Riley
Keymaster

Sorry to hear about your setup!

I am not entirely sure this is not a gcode issue. If they are BOTH doing this (coolterm and tgfx). I am going to see if I cant take a stab at running this on the mill tonight. Also, I do not know how the “work piece” could be “pure carnage” and the simulation or preview look fine. What is the “tail coming off the left”.

Riley
Author

Posts