Is there a $ command value that represents the position that could be queried as the system moves?
I don’t know, but at same time I’m not sure how important it really is to receive the error values. It’s nice to have, but not many people sit there and watch them (I never did).
I would actually say that for initial users, the error values can be somewhat deceiving as they are not X,Y errors but L,R errors.
I agree with the plan here. More than once I have failed to properly connect a motor and the Mega firmware caught the error. It should be completely doable to put the same logic in the Due firmware, it is still tracking encoder counts. While GRBL (which I would call a GCode processor) doesn’t natively have a method erroring in this way, it certainly has methods for limit switches that we could easily attach to and expand if necessary.
I’m not following this bit. AFAICT, the GRBL firmware (same with my sainsmart) will just step up and down. But this doesn’t give me any way to account for a stepper failing to fire due to a loose wire, since there’s no feedback / read mechanism.
1 Like
Hrm, well I must be mistaken and have to look at the Due firmware again then. I thought sys_position was updated via encoder ticks, but if it is just assume to have moved, then I agree this will be more difficult.
Sorry, I am doing this quickly and maybe I should take more time. I am looking at MotorPID_Timer_handler(). It seems to be calculating errors on each “axis”, is axis.axis_Position not the encoder position of each axis?
I guess if it can’t read encoder positions, how is it doing a PID loop?
Sorry I should clearly spend more time with the Due firmware.
Error is being definitely being determined in the M2 firmware (has to be to run PID as you said and you can only get error from reading the encoder). My point was with regards to the “sled not keeping up” alarm and streaming output of the positional error (like the maslow firmware does). Since grbl is designed for open loop, it doesn’t have a mechanism to send positional errors, as far as I can tell. So from a reporting standpoint, all you really can do is raise an existing grbl alarm, which is what I think @zaneclaes is planning on doing. Maybe with that you can filter it in cncjs and throw something on the screen that’s maslow-specific, like “Sled not keeping up OR other error!”
I think the key is to remember that what we have is a hacked version of grbl that was made to work with the closed-loop dc motors (and I’m not disparaging the effort). I don’t think the original grbl part really “knows” that there’s a closed-loop system involed… the motion planner just merrily continues to process the gcode and creating steps for the axes to take and its up to the the PID loop that got added to try to make sure it actually happens. I don’t think there is any feedback from PID loop to the motion planner or anything telling the machine to slow down because error is too high (would be a nice feature to add, though… but that’s scope creep).
Does this mean we could run the maslow from a raspberry pi now?
1 Like
Yup. WebControl works quite well in a pi. This thread is about getting a Maslow to use a slightly different Arduino board with lightly modified generic firmware (grbl) which can then be controlled using Cncjs on a pi. So yes.
@madgrizzle got it. I think we are all saying the same thing then.
Ok, I have thought about this more and I think I know the answer now. I suspect this happens because we don’t have that many test points. This results in more than one calibration having the same error rate. Obviously, the system just had to pick one.
Then when the test is run again, we pick new points. They are the same points but in a new transformation of the coordinate system, so they result in different chain lengths. When these are run through the calibration process the formula is possibly better able to distinguish the correct answer.
I suspect the answer to this is more test points, or at least better measurements to start the process. If the error starts lower there is a smaller universe if possible solutions.
But it is always possible to bounce between two equally bad solutions if no good solution exists (because our model isn’t perfect).
1 Like
Yep! You’re looking for the allowRemoteAccess setting from the README, which defaults to false. Simply adding it to your .cncrc file should be sufficient. Then, just load the IP address + port for your Raspberry Pi in a web browser http://192.168.0.100:8000 (or similar).
I found it in the readme, now where do I find the .cncrc file? I also see instructions to make Cncnjs run at startup but I have no idea how to make that command do anything. Do I need to be inside the makerverse directory in the prompt? Baby steps (saying to myself), baby steps.
I GOT IT!!
I made a file in the home/pi directory and just pasted everything in there that the read me has.
Now to get it to start at boot.
I’ll be including this in the “production” release in the next ~week. The correct way to do it is a systemd service, which is a relatively advanced concept. If you want a quick solution for now, though, type crontab -e and add a reboot script that launches the app, something like:
@reboot cd makerverse && npm run start
Please make sure to refer to my original post, which includes the link for the new syntax of this file. Also, note that ~/ is an alias for your $HOME directory. So the path ~/.cncrc resolves, on a Raspberry Pi, to /home/pi/.cncrc.
1 Like
No, grbl is the firmware that implements a subset of the full set of LinuxCNC gcode on lighter weight hardware. While it may add some extra reporting, configuration variables, and a few overhead commands calling it a protocol is incorrect.
Lighter weight hardware is a bit of a misnomer, I believe the grbl ESP32 on my Zenbot is getting comparable to my LinuxCNC hardware of 15 years ago. But that’s just quibbling
2 Likes
Thanks! It seems it rather conflates the hardware/protocol barrier, or rather, couples them in an unusual way (IME).
1 Like
I’ve been following this thread all week and have huge appreciation for all the work you are doing and impressed with the speed you are getting this ready for the masses.
I see that you are pushing for a production release in the next week. I have been hungry to try this out myself but am now going to hold back until you have that release ready so my system starts “clean”.
If you let me know you have a Release Candidate that needs a final run-through, please let me know and I’ll be a tester.
2 Likes
I am able to get crontab to work but the command doesn’t work. Here’s the result from a regular command line:
Not sure if this helps?
make a bash file (.sh and call that file from the crontab file:
>nano
#!/bin/bash
cd ./[path to makerverse]/ #make sure you find the right folder
npm run start
save that as start_makerverse.sh and see if that will work.
does npm run start work from the command line?