Forum Replies Created
-
AuthorPosts
-
aldenMember
Interesting. It looks like TinyG should fail the homing operation if the max travel is reached. Better than accepting it an having the coordinates be off by some indeterminate amount.
aldenMemberI have been using TinyG to drive the X and Y of a Probotix v90 using these motors:
http://www.automationtechnologiesinc.com/products-page/nema-23/nema-23-bipolar-stepper-motor-425-oz-in-14%E2%80%9D-shaft-with-a-flatPerhaps these are the one’s you are referring to? These are 8 wire motors I have wired in parallel per phase. I don’t quite get full power out of them as they take 2.8 amps and TinyG delivers a bit less than that – the actual current is of course set by the current pots, which are up pretty high.
You could start there and see if you get acceptable results. If not, go to the KL or Gecko drivers. The step, direction and enable are available from the v7 and the v8 boards. There are a few things you should know.
– Be aware that the step, direction and enable signals are 3v outputs, and the enable is active low.
– I have not personally tested either of these drivers with TinyG so I have no guidance to know how well this works or if it works at all. I’m tempted to buy one of the KLs and try it out.
– The code currently in the edge branch (build 412.xx) has some pulse stretching in it. The master branch (380.08) does not. This might not matter. The pulse widths from the master are slightly less than 1 microsecond. Pulse widths from edge are 3 to 6 uSec. Might be friendlier for some outboard drivers.
aldenMemberHey, no problem. To answer your earlier question, the switches are independent by axis. Only the switches in the tested axis are read – the others are ignored until it’s their turn.
The behavior for homing an axis is that if either the limit or homing switch is active during the startup for that axis an additional move is made to back off that switch before performing the search to the homing switch. You figured this out, but I thought it was worth restating it.
aldenMemberHard to know what is going on here. Do the other axes react the same way? Are the limit switches disabled? I have not seen this effect. Can you post your settings?
aldenMemberInteresting thought but probably not a good idea. Each stepper driver regulates current in it’s own clock, so the power transfer would not be uniform. By using an 8 wire, though I assume you will electrically isolate the phases, so it might actually work.
I’ll make you a deal – if you try it and blow up the board (which should not happen – but you never know) we’ll replace it if you provide a full report of how it did or did not work. Be aware that we are out of stock for about the next 2 weeks, so I’d hold off on the experiment for just a little.
If you attempt this let’s sketch it out and discuss things before you try anything. I’m pretty sure doing this w/o driver isolation will have bad results.
aldenMemberIt will be good to check this out. Thanks for the help.
aldenMemberOne other note about arcs – you can somewhat control how many lines are drawn by setting the chordal tolerance value. It’s set very low by default (0.001 mm), which effectively is the finest possible resolution. This can be made coarser and generate fewer lines. It doesn’t change the arc behaviors described above, but I thought I’d mention it.
aldenMemberPWM is also 3 to 3.2 volts, as are all outputs. The processor is a 3.3v process, that’s why.
aldenMember@psyko – What build are you running? We did a lot of work on arcs after build 380.xx. These changes are being staged through edge right now. If that error still exists I’d like to find and fix it. If you have any files that you know perform this can you please make them available (dropbox or some other link, presumably) — Thanks
aldenMemberArcs are a special case, and you are right – they flood the planner. Arcs are actually run as a “cycle”. The arc planner generates many short line segments and sends them to the planner. No new commands are accepted until the arc is complete, which may have thousands of lines.
One possibility if you did not want to fill the planner buffer would be to set the XOFF_RX_HI_WATER_MARK to something lower than 80% full. The RX buffer is 254 bytes, so each 10% is worth 25 bytes. I don’t know if this helps.
Another way to do this w/o XON/XOFF would be to detect the arc motion mode by installing “momo” in a filtered status report. In an arc this will set to either MOTION_MODE_CW_ARC or MOTION_MODE_CCW_ARC. You can use this – along with queue reports – to stop transmission until you see the motion mode move to something else. You can install qr, qo and qi variables in the status report as well, so you =don;t need to enable or parse queue reports, picking these variables up from the status report instead.
aldenMemberHmmm. I see the transmit dialog for as long as Coolterm is reading the file form the disk, then it disappears, but that’s usually well before the motion stops. I think Coolterm is filling it’s buffers, then once they are filled that dialog goes away. Thanks for the clarification.
Hey, If you have that cambam gear file that cut the bad arc I’d really like to see that one. If TinyG is messing up and cutting an arc in that gear we need to fix that. I have not seen that kind of behavior in a very long time, but if something’s lurking there we need to nail it. If we don;t see it, then it points to something else that we should be tracking down. The fact that it’s repeatable in your setup gives me hope that we can reproduce it and find the source of the problem.
aldenMemberTom, when you said you hit the cancel button do you mean “Disconnect” on Coolterm? If not, what did you hit to cancel?
aldenMemberIt is possible to increase the planner queue size but I’d rather leave it where it is for memory reasons. However you are welcome to set to whatever size you need. But 100+ mS should be enough for a UI to react, I’d think (and that’s worse case).
If you want to change the values look in planner.h, here:
/* PLANNER_BUFFER_POOL_SIZE
* Should be at least the number of buffers requires to support optimal
* planning in the case of very short lines or arc segments.
* Suggest 12 min. Limit is 255
*/
#define PLANNER_BUFFER_POOL_SIZE 28
#define PLANNER_BUFFER_HEADROOM 4 // buffers to reserve in planner before processing new input lineOh, and even though the limit is 255 (due to indexing, the practical limit is when you run out of RAM and that’s way less than that (I don’t know the exact number but each queue slot takes about 200 bytes)
- This reply was modified 10 years, 9 months ago by alden.
aldenMemberWe are looking into this. I think what happened is we received a batch of relays that do not fire at 3v (in spite of their specs). We aim to replace these, or barring that at least refund. We are sorry for the inconvenience – I don’t know how this slipped through.
aldenMemberLet me get through the diagnosis and see what we can (and cannot) do with Coolterm. Separately we are qualifying the Edge branch and making sure it works well and works with tgfx. I don’t have an estimate for when this will be finished, but this is what we are working on so it should not be long. Beyond that we’ll make sure you can get your firmware upgraded when the time comes.
-
AuthorPosts