Ok, How long can lead screws be used for this? I still can't get the macro to pull up correctly. I went and uninstalled and reinstalled CONTROL and have pasted the code multiple times, but I get nothing when I click on the icon that is created when the macro is created. The macro still will open correctly and I see the UI if I have it open upon startup of CONTROL, but then I have no way of connecting to the uno without exiting the macro. If I exit the macro and connect, I can't get the macro to open back up by clicking the icon. Any idea what I can try? THANKS!!
[/QUOTE] Yes, and it will open up the macro on startup as seen in screen shot below, but it will not open when the macro "icon" is clicked on the main open builds CONTROL interface. It just does nothing.
Up to 1500mm: with the tensioning system C-Beam® Tension XL Linear Actuator Bundle Macro is not designed as an auto-run macro. Ctrl+shift+i > console log tab > F5 to refresh. Any red errors in log? If not, proceed to connect and then click macro button: any errors?
This? [Violation] Added non-passive event listener to a scroll-blocking <some> event. Consider marking event handler as 'passive' to make the page more responsive. See <URL> metro.js:286 Metro 4 - v4.2.42. Built at: 07/05/2019 22:20:03 [Violation] Forced reflow while executing JavaScript took 61ms main.js:186 VM986 jquery.min.js:2 [Violation] 'setTimeout' handler took 105ms VM986 jquery.min.js:2 [Violation] 'setTimeout' handler took 51ms index.js:83 [Violation] 'readystatechange' handler took 213ms index.js:83 [Violation] 'readystatechange' handler took 729ms [Violation] Forced reflow while executing JavaScript took 32ms viewer.js:358 [Violation] 'setTimeout' handler took 156ms index.js:83 [Violation] 'readystatechange' handler took 1394ms [Violation] Forced reflow while executing JavaScript took 101ms index.js:83 [Violation] 'readystatechange' handler took 2621ms [Violation] Forced reflow while executing JavaScript took 174ms index.js:83 [Violation] 'message' handler took 284ms Thanks!
From your screenshot: Shows its a GCODE macro not Javascript... Pasted on the wrong tab. Delete and recreate the button as a JS macro. Then it will show as:
I pasted it in the javaScript tab, but there was no apply button. So, I had to click back on the gCode tab in order to apply and save. It was still pasted in the javaScript tab, but it was showing as a gCode on the main screen that you pointed out. It wouldn't work, but I just tried on a different cpu and the apply button appears in the javaScript tab and appears to work. I will go back and see if it is there on my laptop.... I apologize it is never easy with me. Thanks!
Yes, there is only an apply button if I go back to the gCode tab. I don't understand why it would display there but not the javascript tab, I have the resolution set as high is it will let me set it on this cpu. Is there something else I can do? Thanks!
Awesome! Thanks! That worked. Maybe I can test it out on the actual saw stop sometime today. I have been looking at the JavaScript written to try and understand it. Is there any documentation describing the DOM? thanks!
Not really, but familiarise yourself with the CONTROL code itself: OpenBuilds-CONTROL/app at master · OpenBuilds/OpenBuilds-CONTROL
CONTROL v1.0.313 (not released yet, still in dev) or later now includes Scrollbars for the Macro Editing window to cater for smaller screens If you note any other windows/wizards where bottom buttons doesn't display on your laptop that has this issue, let me know
Ok. I had a few minutes during lunch and I connected it up to the sawStop. Now that I have the macro able to pull up, and it does appear to work. I still need to do some tweaking to set my $27 so that it will start in the right place(homing is not dead on 90" like it should be);, and I need to adjust it so that I am homing to axis max like you described earlier, but I'm not sure how. The way it is now, I am backwards to what I want. If I type 35 Inches it moves to where a 55" board would be cut if I pushed it up against the stop because my homing 0,0 (axis max) is at 90" from the blade. I also have a minor issue with accuracy that I have had with both codes (mega+uno) and now (control interface). It doesn't really make sense to me, and I am not sure I can explain it. If I press 45" it goes to the 45" but may be off by as much as 1/16th. If I go back to 0 it is dead on accurate. If I go to 46" it will be off as much as 1/16th, BUT (here is the kicker) if I go from 46" back to 45 (that was just off slightly) it is dead on accurate. To be dead on accurate I have to go past where I am trying to go and then come back to the actual destination that I want (accurate moves are stepper turning clockwise). Even stranger thing is (using code that required mega and uno) if I changed so that 90 was subtracted to go to the correct location from the blade, the accuracy was the exact opposite of what I explained above. The "correction" move would be with the stepper turning in the opposite direction (counter clockwise) than described above..... I am sure that is hard to follow, but I hope to get a video of it at some point. Maybe it will make more sense then. THANKS!
I am assuming the endstop is on the far right. I am right handed so in my head you are sliding stock under the saw from the left and the kept cut piece is on the right. Fence moves from right side of saw blade (Work Pos X=0) to X=90" when its furthest away right from the blade. Then $23=0 (Grbl assumes by default switches are at axis maxima. If you move the switch away from that assumed position to the other end, then that axis needs inversion. In this case we do want it on the axis maximum so the default of $23=0 is perfect for us. Jogging X+ should move the carriage toward the switch and switch is mounted on the far-right of the beam (if not fix wiring or $3-DirectionInvert) Homing should also move the carriage toward the right to go find the switch You don't set that offset with $27. Machine zero is where the switch triggered. $27 pulls it back to clear the switch - but zero is already set earlier when the switch activated. No your offset is set with the SetZero/G10L20 that you hit when you have the fence barey touching the carbide tip's side on the blade Mechanical... Likely loose grubscrews on pulley - slipping on shaft under direction change / load. Or belt slipping (not tensioned correctly)
I may should have provided this earlier, but this is a video I took prior to making the change to CONTROL. This may help explain my setup better. My saw blade is to the right. The limit switch is to the far left (90" away from the blade). I pull the saw handle with my right hand and the board that I want to keep is to the left. The board i am discarding is to the right. https://www.youtube.com/shorts/DWNdFOfxgMc Thanks!
OK fair enough, that does add confusion - but in terms of "distances" - 0 = touch the blade, and +90 = away from the blade - your mechanism doesn't comply with the Cartesian Standard, but maybe best to just flip that in your head. X+ moves it left, X- moves it toward the blade (x- = minus = less distance between blade and fence. That's more mathematically correct, though the buttons' arrows will be pointing wrong way round. )
Ok, I'm not worried so much about the X+ and X- buttons, but if I type 22" in the macro, I want it to move to the 22" spot on my external ruller (22" from the blade). Do I need to change my $23 setting for this? Thanks!
To achieve that you have to comply with $23=0 (homing to axis maximum, which is far left in your case) X+ jog moves toward the left away from the saw (+distance), X- moves it closer to the saw (-distance) Use SetZero/Jogging to position your fence accurately against the blade and SetZero (work coordinates)
Can I do this in your code? sendGcode("$J=G90 G20 X" + sawStopFinalPosition - 90 + " F10000"); If I am understanding the code correctly, this is basically how I was doing it before when I was using (mega, lcd, keypads etc..) Thanks!
You can but if you do: You won't have to. Its logical, setzero at the saw, move positive directions away from the saw. Easy, no math
But, then I would have to manually set 0 up against the saw blade prior to using, right? This way, I click home; it finds limit switch and sets on (90" from the blade) and any input I use would be changed (mathematically) within the code to be on the desired number. Similar to the way CONTROL changes mm to inches (just for looks). Please don't take this as me trying to say I know more, I clearly don't.... I am just trying to wrap my head around it all. Thanks!
Just once (and whenever you change blades) Offsets are stored in EEPROM. It's a non-issue! Again, HOMING sets MACHINE COORDINATES (And NOTHING you will be doing will touch Machine Coordinates anyway) Zeroing sets WORK COORDINATES and that's where YOU will be moving in And as Work Coordinates are just an offset stored in EEPROM of how far away from Machine Coordinates you were, Rehoming on powerup magically restores the work coordinates to what they should be
Ok, so as long as nobody clicks "set 0" after I have "set 0" up against the blade, it is set forever.... The homing calibrates but doesn't change the work coordinates. I think I am understanding better now. Hopefully I will get more time at the actual saw soon. Thanks!
I just thought of why this is going to be problematic for me. My saw stop will not reach the saw blade. Because of the physical location of the idler gear, it is (at the moment) several inches from the blade. I do plan to get it closer, but I don’t think with the one I have I will have enough room to actually get there, and I have never had a need to cut something less than 1” any way…
so, I should go to 5” (if that’s as close as I ever want to get from blade) from the blade and type in the console G10L20X5?
