- This topic has 5 replies, 2 voices, and was last updated 5 years, 11 months ago by .
-
Posts
-
hello
2 questions(1)
the ebb documentation say
“The EBB firmware can sustain moves of 3 ms of more continuously without any inter-move gaps in time.”
(a)I guess it is “or more” instead of “of more”
(b)What does it mean ?(2)
dividing by 25 the max of absolute value for each axis should give the minimum time for the movement.
Infact the ebb software check the command validity of speed this way.
But in most cases the axidraw “crack” and don’t execute the command correctly.
too much acceleration required I guess.
if I divide by 12.5 ot seem the be ok.
increassing this number increase the probability of problem.
How to deal with this, without being half the maximum speed ?
What is the constraint ?Thanks
Maa(1a) Thank you for the typo correction.
(1b) It means that moves shorter than 3 ms may not be reliable. Keep your moves at least 3 ms long.(2) You say “But in most cases the axidraw “crack” and don’t execute the command correctly.” I’m not sure what you’re saying — if something is breaking, please contact us via e-mail and we can work with you on the repair. If the EBB is not executing a command correctly, please let me know exactly what command you are executing, and in which way the behavior was not as expected.
The EBB firmware gives an upper limit for how fast it can generate steps. That is not the same thing as saying that the machine can physically move at the maximum step rate that the firmware can produce. The maximum physical movement speed (as in steps per second) depends on the mechanics of the machine, the resolution selected with the EM command, and how fast or gently you have accelerated.
(1) There is a certain amount of parsing and processing overhead.
(2) Yes, if you try and run at very high speeds without acceleration, you can cause it to fail.
There aren’t any rules here. Outside of the AxiDraw software, you can easily enter raw movement commands that are faster than the AxiDraw itself can move or accelerate. This shouldn’t be surprising.
It *may* work, but we don’t test with these kinds of parameters, nor guarantee it to work there. (We also don’t guarantee that you can’t cause physical damage to the machine by testing the limits in this way.)
You’ve already seen axidraw_conf.py, which is where all of these parameters are given. (I’d suggest to work from the copy included with the CLI, which has the latest values.)
This is the file that sets the size limits, speed limits, acceleration rates, and so forth as used in the AxiDraw software. The values tend to be on the conservative side (especially with respect to things like the time steps used) since people’s computers vary quite a bit. If you want to experiment, working at around those values will likely be a good starting point.
- You must be logged in to reply to this topic.
