Forum Replies Created
-
AuthorPosts
-
jpistorinoMember
Thanks.
I see in response to my earlier question, you did say “use G1 …” and I just missed it.
I will reflash with the newest version.
For me (and possibly JuKu), the buffer size is not an issue as I am not processing a GCode file. Instead I am issuing GCode commands in response to keyboard input. So far, I have only seen two or three commands in the buffer at one time. I did first think of this as a source of the problems but verified the length of the buffer. In any event, it is a good thing to keep in mind.
jpistorinoMemberOK. Let me try that.
BTW, if John Lauer monitors this forum, I think this is a better approach than what he is using to jog in Chilipeppr. He issues a series of G91 and G90 commands as long as the key is depressed (the keydown event issues one and, as long and the key is held down, there are are series of keypress events that result in more commands being issued). At least on my machine, that leads to a very stuttering type of movement.
The approach I am trying gives you smooth movement. You detect keydown, ignore all keypress, and detect keyup events. As long as the travel rate is fairly slow, you get smooth movement and control.
jpistorinoMemberWas this issue ever fixed other than by careful rearrangement of the commands?
I am writing something similar to JuKu where I issue commands in realtime to the TinyG. This is for a jog feature.To implement it, I do the following:
1) record the maximum travel velocities of all the axes (XVM, YVM);
2) detect an arrow keydown event;
3) reset the velocity of the axis of move direction to 1/10 of the original;
4) issue a move to maximum travel distance in the desired direction;
5) detect a keyup event;
6) issue a “!%” to cancel the move and clear the buffer;
7) reset the travel velocities (X and Y) to the original values (using XVM, YVM).After issuing the last XVM and YXM commands, I get:
{“er”:{“fb”:438.02,”st”:9,”msg”:”File not open”}}Attached, is a screenshot of my app showing the commands sent and responses received.
I suppose that I could issue dummy move commands between the velocity resets but that seems like a bandaid approach. I also know that I am not using the most recent firmware version.Any ideas on the best way to resolve this?
Thanks,
JamesjpistorinoMemberJohn,
i have a quick question on implementing a jog feature. What is the best way for me to reach you? No email address is here in this forum.
Thanks,
JamesjpistorinoMemberI had the same issue of needing dual axes and an orientation. Here is a link to the thread discussing this. https://www.synthetos.com/topics/networking-two-tinygs/ While I have not tried it yet, the solution of using J17 and external drivers seems like it should work.
Regards,
JamesjpistorinoMemberThanks. That got it working.
It is generous to call me a “developer.”
More like a guy that knows enough to be dangerous.I am using the version that came on my TinyG v8 but I will switch over to the edge version.
Thanks again.
jpistorinoMemberThanks Juha.
It it interesting because those fids are both: 1) not unique (i.e., you cannot distinguish between two fids except on expected location); and 2) they are rotationally symmetric such that you need two to determine skew, etc.
I am looking at the fids used in augmented reality as an alternative.Still hoping that John is Bay Area and that we can talk.
Regards,
JamesjpistorinoMemberI will take up Alden’s offer.
Juha,
I knew that you were in Finland and your project is great.
You are a few steps ahead of me.
When you say “industry standard”, can you point me to something that has details about the fids?Thanks,
JamesjpistorinoMemberJohn,
I would be up for collaborating as well though most of my efforts so far have been on the vision side and I am not sure how much I can help you. Can you shoot me a note as to where you are physically located? We are working along very similar lines. Your project is awesome.
I am curious to know if you are using fiducials to align what the camera is seeing with the real world of the CNC domain. If so, how do you do it, what fiducials are you using, and how did you fabricate them?
jpistorinoMemberThanks Alden.
I suggest that Synthetos offer this as a TinyG accessory: an expansion board that can be connected to the pinouts to drive dual axes while preserving four axis control. Anybody that is already using all four axes, can add dual driving to one or more of them of them. Anybody that is already using dual drive, can now get access to another stepper motor. All of this for ~$15-25. A little ribbon cable so that you can mount the expansion board somewhere and you are all set.
I will try it and let you know how it works out.
Thanks to you and ascott.
jpistorinoMemberThanks for your help.
I will wait for Alden to weigh in but this would be great if it works.
It essentially adds another motor control to the TinyG for $12 for a dual gantry configuration.
Dual gantry is probably the most common larger scale configuration so you use up all the drivers.
If it works, I would suggest adding a wiki page/promoting this as it would fill what I expect is a need.Alden – what do you think?
jpistorinoMemberI am in favor of anything that works and is easy.
When you say “motor 1 pinout” is that J17 such that I could attach a http://www.pololu.com/product/1182 to it and get the drive both X motors?
If so, would the fact that you are using two different drivers (one on the TinyG and the Pololu part) be an issue?
If this would work, this would seem to be a fairly easy answer and could solve a need for five motors. I would think that many people are using dual motors on one axis of their gantry. Thus, they run out of space to drive anything else requiring a stepper motor.
jpistorinoMemberThanks Alden.
I am trying to build a pick and place machine similar to OpenPNP. The four drivers on the TinyG are used for the gantry with dual X drive. However, you have to correct the orientation of the picked up part and that requires another stepper motor (a NEMA 17). Thus, there is no requirement to coordinate the orientation motor with the XYZ axes. You juts get to the right physical location, then correct the part orientation.
Would attaching the Pololu part I referenced to J17 work on the hardware side?
If so, how would I reference the fifth motor on the software side?Thanks,
JamesjpistorinoMemberThanks Alden.
I will try my luck with a question more specific to my project.
I already have a TinyG that is working fine with my CNC with dual X motors driving the gantry. My project basically uses a 24V power supply for everything. My project will need an Arduino (of some kind) as well for some adc and other stuff. I had been planning on operating the TinyG and Arduino independently. Right now, I am starting to write a JSON interface to control the TinyG.
I already have another TinyG, so if connecting them was a relatively simple task, then I would do that. Alternatively, if there is something simple that I could interface with my single TinyG (like hooking http://www.pololu.com/product/1182 to J17 as I think flux suggests) and do this that would be great.
Alternatively, I could go with multiple gShield but would have a lot of questions.
For me, price is not really an issue but getting something to work quickly is. I am a hardware novice and am looking to focus more on software.
What do you advise?
Thanks,
JamesjpistorinoMemberMy motors are 3 Nema23’s and one Nema17.
The fifth motor would be a Nema17 or lower.An “end effector” is something placed where the router would typically go.
In the normal CNC application, the router is the “end effector.”Thanks,
James -
AuthorPosts