That is not something that has been implemented, it would require adding new code to Smoothie's source.
I noticed that in original Ultimakers the knob for selecting files is "circular"; meaning that after the last file is seen it jumps back to the first line of the menu again.
Also when you rotate the knob counterclock wise you jumb automatically to the last line of the menu, or in case of the files in your directory of your SD card the last file.
Is there a way to implement this in the Smoothieboard + GLCD as well?
And what do I need to change to the CONFIG file to get this done?
in discussion Smoothie Firmware / General » Need your opinion on the documentation, help us improve it
Having a clear, exhaustive and user-friendly documentation is one of the core goals of the Smoothie project.
We have put a lot of work into what we have now, and we get quite a bit of praise for it.
We are also currently working on producing video documentation, though that's a long-term goal.
But nothing is perfect.
I've recently been working on improving the documentation further, and I think I have a hard time putting myself in my shoes of the "average" user sometimes. I know where everything is and what everything means.
The thing is new users don't.
What do you think could be improved ?
What did you search and not find ?
What was not clear enough ?
Do you have ideas of how to structure some things better ? Add pointers in some places ?
Are some things too cryptic or too advanced ? Are some not enough ?
If you take just a few minutes to give feedback on your experience with the Smoothie wiki ( http://smoothieware.org ) and your ideas on how to improve it, you will be helping to improve the documentation, and making the life of new users easier.
I can't promise I will fulfill everyone's wishes or implement everyone's ideas, but your comments will definitely help push the documentation in the right direction and make things better.
Thanks in advance.
Ok, well would be great, but it could also be pre-calculated, especially as all axis will be synchronized anyways.
Ill do a drawing and add the math, maybe someone would like to look at the code with me from there.
I have no idea if that's possible for new arm solutions. It's not the case of any existing ones.
That's great, that will look stunning if in motion!
So you can use XYZ axis for fancy arm solutions, but just not the ABC. But it is still possible to use the ABC parameters in the XYZ calculations, i assume.
actuator_mm[ALPHA_STEPPER] = fantasyMachine_mm[X_AXIS];
actuator_mm[ALPHA_STEPPER] = fantasyMachine_mm[X_AXIS] + fantasyMachine_mm(A_AXIS);
But than with a bit more complicated math off course…
Saying it doesn't go through the arm solution just meant it is not concerned by things like delta kinematics.
It is still synchronized thought, they same way extruder axes are for example.
I'm working on a 5 axis pick and place machine. There is basically a XYZ coordinate and 2 angles that should make the machine move to the requested position. Its ok if the ABC axis show some movement error in timing, as long as they arrive at the good position, before the machine traverse to the next line of code.
From understating this line:
NOTE that the parameters passed into A B or C in a G0 or G1 are raw, they do not go through the arm solution, they are the values that will be passed to the stepper based on steps_per_mm for that axis (although it may be interpreted as steps per degree for instance).
So the ABC axis are not taking part in the arm solution, BUT can I use the ABC value's in the kinematics section to make the right offsets based on the ABC value's?
If i understand correctly, it might not make Axis B arrive at the same time as the axis that take part of the arm solution calculations (XYZ), but it would still end up in the proper location.
Is the above correct?
PS, I love to do the maths for the kinematics part, but I'm little blow away from all the code. I can program C/C++, but if at some point someone would like assist that would be great.
We currently don't support M0 but it is a planned feature.
I do not believe M600 can be made to work the way you want.
You can however add a "pause" button to the machine if you want : smoothieware.org/switch
Then, you will be able to insert M600 into the gcode to pause, and then press the button to start again.
I believe the temperatures are in fact displayed on the panel.
The panel also shows the current percentage of completion of the currently playing file.
I think the forum or mailing list for your slicing program is a better place to ask for help for this particular issue.
But you can post your start gcode here and see if somebody has an idea.
If your motor is rated at 0.5A, you need to set your config's delta_current at exactly 0.5A
About the skipping, please check that all 4 of the wires really go to the motor driver, and that there is not a wiring or connector problem, this is the most common cause of what you describe.
I want to use a Nema 14 stepper motor to drive my extruder. But skips no mater how may time I change the settings.
I am using Pololu 200 Steps/Rev, 35×28mm, 10V, 0.5 A/Phase
My Settings are:
[[## Extruder module configuration]]
[[extruder.hotend.step_pin]] [[2.3 ]]
thank you for any help!
Can you try using another host like pronterface and see if the problem still occurs ? This is for debugging only
Last night I experimented more. This was much better but not the fix that was needed. Using the same Gcode file and running the laser cutter without changing position you can see that the slow down is somewhat random in nature and occurs at different places along the cutting path. I am going to try another smoothieboard that works in a 3d printer I have to see if this is board related or something else causing the problem. I have noticed when moving the gantry manually it randomly slows down and moves very slowly.
Where do you think would be the most adequate place to put such a warning ?
First, sorry for the unnecessarily goading tone of my last post. That was uncalled for.
Being a software developer myself I can certainly appreciate the complexities of this feature.
Would it make sense to add a warning to the documentation that soft limits are not yet supported and users have to be careful when manually jogging the axes?
in discussion Smoothie Firmware / General » G32 on Delta- Effector bumping near towers when probing.
Try formatting the SD card, and starting from a fresh configuration file.
It's called "soft endstops", and it is the only feature that other firmwares have, that Smoothie does not have yet.
It is a planned feature, but because of things specific to Smoothie, it's much more difficult to implement correctly for Smoothie.
Actually no that's not normal behaviour.
Can you make a very small gcode with different gcodes and very very different feedrates for each of them, and see if this is really what is going on ?