I had an idea the other day and I want share it with you guys and ask if you think it would be worth pursuing. Right now I am using the LCD screen to home the machine then move to my material origin so I can set the offsets. This is a very slow process from the LCD screen. You have to go into Prepare-Move Axis-X,Y or Z Axis, .1, 1 or 10mm then you can move one axis at a time. So slow especially if you need to use the .1 to fine tune.
So I looked into some of the options available today. Options:
I could use Repetier host on a PC. That is my easiest option but I am having trouble getting it to connect. I think I installed repetier host server and that is causing a conflict with the port.
I could use Octoprint with a raspberry Pi. Cool but It will take me some precious tinker time to get setup.
I have seen the keystone with buttons project. I think It also uses Octoprint.
In any case I know there are options but I thought of another option and I want to see any of you think it would be worth trying to submit a feature request for. What if I wired up 6 momentary buttons (switches) to the X, Y, & Z Min and Max pins. These new buttons could even be used in serial with (normally closed endstops or parallel with normally open) actual Min and Max endstops. So these buttons would not hinder normal endstop functionality. I could place these new buttons near the LCD controller with labels like +X on the x min and -X on the x max. I will explain the opposite labeling in a moment.
Then this is how I would envision it would work. From the LCD the user would click Prepare - Move - X, Y or Z Axis (meaning one menu option for all three instead of one option for each.) Then the LCD would display three speed settings Micro, Normal, Fast. At the bottom would be a message to click to exit. It would show “Normal” highlighted/selected to begin with. Then I would click my buttons to move the X, Y and Z axis around manually. If I press and hold the button to move +X then it would continue to move the X axis until I release the button. Then without changing anything in the LCD menu I could press and hold the +Y button and release then press the -Z. If I want to change the speed of movement then I turn the dial on the LCD to select slow or fast. Click it when done. Then a menu option right there to set that position as the offset would be nice. (I think it is already there but It doesn’t work for me on version 1.1.5)
Why is this a good idea?
Instead of sending a command to move +10 mm along an axis that could crash the machine if there isn't that much room available it would instead be sending real time commands to the controller. The button is pressed right now so move right now in that direction at the selected speed.
This would be a lot faster to use than the current Move Axis options from the LCD.
This would require minimal hardware to get to work. No raspberry pi or other controller software. Just 6 momentary buttons ( switches) and some wire. It could even be 3 momentary switches that can support dual directions up and down and share a common wire.
What if the manual movement triggers an actual endstop? This is why I would use opposite directions for the pins. Let's use the X axis for an example. If I am trying to move it in the Negative direction. So I am pressing a button labeled -X. But this button is actually wired to the X max pins. This is by design and the firmware would know it. So the machine is moving in real time along the X axis in the negative direction. Then it hits the X min endstop. The firmware suddenly sees that both the X min and the X max buttons or endstops are triggered so it stops moving. That way it prevents the machine from crashing. The same would be true if the machine was moving toward the X max endstop as well.
So this mod could be implemented on a machine with or without existing min or max endstops. It would require minimal hardware and it could be enabled in the configuration.h file just the current move axis features are. It would be faster and easier to use.
I am a programmer by trade and in the past I have helped implement some features in the Repetier firmware specific to the XYZ Printings Davinci Duo. But I know I don’t have the time or energy to implement something like this anymore. My life is too busy these days with 3 little girls at home. So the best I could hope for is to submit a feature request and hope for the best down the road.
So I am asking my friends here first. Is it worth it? Should I submit the feature request on the github issues forum? Or should I just let the idea die and go with one of the options I mentioned earlier?
a) The octopi image or my v1pi image make it pretty simple to set up octoprint. Better, IMO than running a USB to a laptop all the time.
b) Jogging over the serial commands, from something like octoprint needs to be handled specially. In fact, the 10mm steps are also handled wrong, which is one reason why it’s such a pain. The main problem is the planner. The second problem is acceleration. If you’re jogging, you might want to consider a different command path. I thought I saw someone was implementing something similar. I’m pretty sure grbl has something like this for treating jogging differently.
c) your design for the buttons is terribly clever, and I really like it. I would give that feature request a thumbs up. BT was looking for more PRs to do. Maybe he would be interested?
The problem with endstops is that they have to be handled as fast as possible, so i guess they handled in the movement isr. It’s pretty low layer of the movement stack. This idea tries to mix high level logic (control of the machine by user) into low level critical part of the system.
There is a lot of problems you have to solve:
Normally NC endstops used for safety. If the cnc is stopped and lose connection to an endstop - it will start moving to opposite side? Is it good?
How to use it for a diy cnc with dual endstops?
The code which handles endstops should do this trick only at the moment when the cnc is stopped. (Even not in the state when it moving to desired direction - it already under control of something action). Anyway, this movement have to change machine coordinates, so have to inject “commands” into a few layers upper then endstops code exists. And what to do if at the moment someone passed movement gcode?
Controlling by gcode is straight sequential predictable approach. And, honestly, i didn’t get what is the problem here with positioning precision
mmm, I don’t know. There are interrupts for catching endstops, but they don’t have to be long to capture the state, and let a higher level of code read that state and act on it. Similar to the M119 macro. You’re also not controlling them from a PWM signal, so a couple of taps from the slow human won’t kill the timing (or else I would have already when I tapped the endstop buttons).
As i remember, by default own interrupts not used for handling endstops and not all pins used for endstops are interrupt capable. So endstops polled. But polled in the code that drive steppers.
Â
If you ask me how i can solve such task strictly without using any external cpu (even small nano)- i can propose to connect a few buttons from voltage divider build with a few resistors to an analog input pin and add small code into Idle function which will check voltage on the pin and inject gcodes into end of conventional pipline
I shouldn’t be arguing with you. But IIRC, analog reads take a long time in arduino. The first draft I would do is just to disable endstops, but use those pins anyway and map them in pins.h. When that was working, I’d try to figure out how to re-enable the endstops. I doubt it would be more of a change than some of the other ifdefs.
That is ringing a bell. But somewhere in the loop or idle, you can easily test this polled and stored value and do some pretty darn quick logic to add something to the planner. IMO, the trick is bypassing the planner altogether, and combining this with the state of the LCD (again not hard if you have access to the state). If the motion code has the ability to clear, shortcut, or bypass the planner already, then I think this makes a lot of sense. You really wouldn’t want someone to hit it a few dozen times and it would try to go 2m along X. As soon as the button state changes, you should clear the planner and go in the new direction.
Well you guys understand the hard part much better than I do but I can say a feature request doesn’t go far. You have to send in a complete or nearly complete pull request to get in the frenzy of changes.
Really though V1Pi is as simple as it gets. I can do it in no time and I code like I learned it from a fisher price book.
Well, Thank you for the full discussion. I had not seen that particular G-Code Sender before. That looks pretty cool! But I think I will follow the V1PI option since it seems like it would be the easiest solution for now.
By the way i bought two raspberry pi 3 and two lcd touch screens - 800x480 (resistive touch, hdmi+spi) and 1024x600 (capacitive touch, hdmi+usb).
And I have disappointed that there is lack of gcode senders adapted to touch and small resolutions. Octoprint has touch ui plugin and repetier server (in trial/paid version), but they both dedicated to 3d printing needs.
Cncjs in stock version doesn’t fit even to bigger of my screen. There are 2 third party skins for it, but i haven’t test them yet.
IIRC when Estlcam was testing support for the Arduino/RAMPS combo he had Marlin talking to a joystick for moving around, how about asking them to support that functionality. You could move fast with the joystick and slow with joystick and trigger combo.
That needed a whole windows machine though. Cnc.js has a plugin for supporting ps3 conteollers and knowing what I know about linux and joystick devices, it should be easy to edit that for a local usb joystick, but you still need a pi.
Yeah, I wasn’t remembering it right. He had the joystick connected to the Windows computer instead of the Arduino. Most, if not all, of the typical controllers don’t really have a spare port for the joystick to connect. Their USB implementation isn’t quite that flexible.
You could probably replace the knob with three switches. Up, Down, Enter. You could use some nice mechanical keyboard ones and be out all of $1. That would require some changes in the config, but no code changes. It would require some code to support holding down a switch to make it repeat though.
Easiest might actually be an eensy with a USB host shield to read the joystick and have it then send gcode to your controller. There are lots of USB joystick libraries for Arduino. With a 32bit controller solution you could just connect the joystick through a USB host shield and do it within the OS.