Reading the other information first helped me understand that. I even know that the completedMsg is set to false because I don’t need a pop up that shows after the code completed. Thank you for sharing that information. Sorry one more question, can I access the maximum travel distance for x and y in a script? For the purpose of moving to a probe plate that is embedded in my wasteboard (located at 25,25) before running a Z probe command. I figure I have to set it to G53 X-3600 Y-2400 F10000, but I am not sure how to pull up those figures. I might also need to drop the Z down a little in the macro because my maximum Z distance seems to be too far for the probe unless I move it down first. I think I have about 50mm from top of Z to touching the plate.
That's front, left then: Grbl Max Travel values are available (after connecting to a board) under the grblParams json object: Note they are strings, to use them in math (the 25mm offset) you might need to do var xMaxTravel = parseInt(grblparams.$130) or parseFloat(grblparams.$130)
hello, i have a questions, can some1 write a makro that changes the position of the x and y jog buttons? my machine sits left to me, so everytime i turn the head i need to think, wich button to press, if u know what i mean so it would feel more natural/comfy regards dave
Anyway to programmatically set the zoom scale in the 3d viewer? I spent some time digging around and couldnt find anything that worked. dollyIn maybe? Working on a widescreen ui macro that will add a right side container to control when expanded. You can swap tabs in and out of it. The 3dviewer is fine on my desktop monitor (16:9), but on my Surface (3:2). I really dont want to adjust the render size because it defeats the purpose of the widescreen . I was hoping to solve it by setting an initial zoom scale after your fixRenderSize function fires. Something like camera.dollyIn(4)
Initial zoom is set from viewExtents function, used by resetView (called after window resize, file load, button, etc) May need to fudge around with the values in there
I found two different ways to do this, but I just realized that Control has a similar issue when the object isnt square. So I've decided to live with it for now. For anyone else looking at this I found you can use controls.object.translateZ() or camera.position.z
Peter, Instead of running gcode from the editor, is there a function to call another macro with gcode to run. I would like to run a gcode macro with the dialog box so the operator can confirm they are running the correct one (and run it just once) Thanks, Dina
You could call another macro from a macro yes. See OpenBuilds-CONTROL/macros.js at ef770352c4bc254c30e12548e268cc09ae08b0eb · OpenBuilds/OpenBuilds-CONTROL but I wouldn't use it for this, as the order of the buttonsarray might not be consistent Build the dialog using MetroUI, into your custom macro - with the JS you can do anything
Thanks, I'll try to have the dialog and depending on operator input select a macro (which I can hide all but the JS one). The macros will have the same buttons array to what I set it to.
Can someone point me in the right direction please. I'm trying to set up a macro to auto connect to the controller at startup on the same com port. I'm trying to automate a cnc to run the same job every time a button is pressed. Thanks
You can send a Socket event like this: Code: var data = { port: "COMxx", baud: 115200, type: "usb" }; socket.emit('connectTo', data); Borrowed and shrunk down from the source code: OpenBuilds-CONTROL/websocket.js at master · OpenBuilds/OpenBuilds-CONTROL
I have created a macro for comparing the result of a z probe to the previous probe. My goal is to test probing repeatability and the macro is working but it causes OpenBuilds Control to become unresponsive. This seems to affect the DRO and console input the most. I put this together with code that I 'lifted' from one of the macros posted on the forums, can anyone help me to understand what I have wrong? Code: ;PROBE HEIGHT DIFFERANCE socket.off('prbResult'); // Disable old listeners var probeTstMacro = ` ; probe z G21 G90 G59 G0 X0 Y0 Z-25 G54 G38.2 Z-50 F150 G4 P0.4 G10 L20 P1 Z9.5 G21 G90 G59 G0 X0 Y0 Z0 G54 ` socket.emit('runJob', { data: probeTstMacro, isJob: false, completedMsg: false, fileName: "" }); socket.on('prbResult', function(prbdata) { if (prbdata.state > 0) { var difZ = laststatus.machine.probe.z - prbdata.z; alert(difZ); socket.off('prbResult');} else { completedMsg: "nope"; socket.off('prbResult');} })
Your first line isnt valid javascript. Javascript comments are // not ; Comments for gcode use ; so change ;PROBE HEIGHT DIFFERANCE to //PROBE HEIGHT DIFFERANCE Also, use the chrome inspection tools to debug your code. With the window focused, press ctrl shift i. Then look at the console tab. Here's what your posted code produced
This caught my eye That laststatus = may already contain current probe's data (depending on whether status or prbresult emitted first) I'd recommend storing your own array of probe results each time one comes in That way you can also have more than last and current to compare - helping check wider average
Thanks, you are right. I am pretty sure that first line was not actually in the code that I tested but just in the text file where I stored the code. I will make it a goal to become more familiar with the console. so maybe like this Code: //PROBE HEIGHT DIFFERANCE var lastZprb = laststatus.machine.probe.z; socket.off('prbResult'); // Disable old listeners var probeTstMacro = ` ; probe z G21 G90 G59 G0 X0 Y0 Z-25 G54 G38.2 Z-50 F150 G4 P0.4 G10 L20 P1 Z9.5 G21 G90 G59 G0 X0 Y0 Z0 G54 ` socket.emit('runJob', { data: probeTstMacro, isJob: false, completedMsg: false, fileName: "" }); socket.on('prbResult', function(prbdata) { if (prbdata.state > 0) { alert(lastZprb - prbdata.z); socket.off('prbResult');} else { completedMsg: "nope"; socket.off('prbResult');} })
Your gcode is a bit strange as well. You have this for your first line of gcode G21 G90 G59 G0 X0 Y0 Z-25 It should be split up into two lines if you actually want it to run the G0 command. G21 G90 G59 G0 X0 Y0 Z-25 But then that brings up another question as to why you want it to plunge 25mm as its first move. Also, you are specifying G59 but probing G54. Similar issue with the 2nd to last line of code. And also, if it were me, I wouldnt issue a G10 to set work zero. Since the tool and probe aren't moving, I think its best to keep zero where its at. All you care about is reporting the diff in probe triggers. How about you tell use how you want this routine to work and we'll help you figure out the gcode.
well... here is my goal with the gcode part I have a 0 set in G59 this is high above a tool length offset probe for tool changes. I was shooting for the following steps. 1. rapid to a position 25mm below the tool change position 2.probe, I don't necessary want to change the z0 just get it to report. maybe I can drop the 'G10 L20 P1 Z9.5' completly? 3. display the difference between the result and the previous probe 4. return to the high G59 position to allow for tool adjustment
Got it. Okay why? If you're testing repeatability, dont you want to keep the tool exactly how it was during the first probe? FYI - I went through all of this when I wrote my tool change wizard. I was using a momentary push button like most diy'ers out there. The repeatability sucked. It was worse when the tip of the flute was off center (which is always the case when using single flute endmills.) Anyhow, to test it, I'd never move the tool in the collet. I'd probe, rotate the bit, probe, jog around, probe, etc.... I ended up building my own "push button" using a precision dowel that rides in a precision bushing above a proximity switch that works perfectly. The dowel and bushing remove any side to side motion in the spring. But, as far as your macro goes, you might want to consider logging the results to Serial Console. Using alert will keep the tool touching the probe until you clear the alert. Also, its nice to have the difference logged instead of writing it down. First, here's the gcode I would use. You can modify it for all your G59 stuff if you want. Code: G21 ;Make sure we are in mm G38.2 Z-25 F100 ; probe z G4 P0.4 $J=G91G21Z5F1000 ; lift bit 5 mm above probe Here's the updated macro. I've only tested at my desk, not the machine. Assign a keyboard shortcut to it so you can keep the Serial Console tab active. Code: var lastZprb = laststatus.machine.probe.z; socket.off('prbResult'); // Disable old listeners var probeTstMacro = ` G21 G38.2 Z-25 F100 G4 P0.4 $J=G91G21Z5F1000 ` socket.emit('runJob', { data: probeTstMacro, isJob: false, completedMsg: false, fileName: "" }); socket.on('prbResult', function(prbdata) { if (prbdata.state > 0) { socket.off('prbResult'); printLogModern('', 'ProbeDiff', (lastZprb - prbdata.z).toFixed(2), 'fg-orange'); //alert(lastZprb - prbdata.z); } else { completedMsg: "nope"; socket.off('prbResult');} })
Yes for repeatability testing you are correct. I had it moving to those locations thinking this macro might evolve into a tool change macro some day. Cool I am curious about your push button, is there a post about it? Thanks! testing this right now and the macro is working great thanks why did you write this line this way? .
Good spot: It would cause the probe to fail if tc_retract was more than 5. It shouldn't be tc_seekdistance, however as that is for the initial probe to locate the tool setter - I envisage that this could be quite a long distance and would cause travel limit errors if started from too low a height. It could be something like Z-(tc_retract +5), or I could just stick another variable in to be able to set it at the top of the macro. I'll probably go with the latter. Will re-post after testing. Thanks.
I have updated the code / file in the original post to V1.1 in response to the above. There is now another variable at the top of the file (tc_probedistance) that can be used to set the distance for the tool length probe once the tool-setter has been located - the tool should be roughly the distance specified in tc_retract above the tool setter at this point, so tc_probedistance only needs to be a little bit more than that. Let me know if you spot anything else Thanks, Andy
I have just tested this on a BobsCNC EVO4 and it took a bit to figure it out, i didn’t have a previous code loaded. So i moved the machine to a location just outside the probe, zeroed the z to the wasteboard. I had G28 and G30 preset. Ran the macro and set reference tool, moved to tool change location , adjusted length of tool, then set new tool, it all worked great. Gonna do some more testing, but it looks good so far.
Glad that it seems to be working for you, and thanks for the feedback! Was it something to do with using the macro, or just the process of getting it installed? If I can improve anything with the usability, then I will.
Well most of the issue was that i didn't home it before I ran it. so that was very important, could the program check first and offer that? it was easy to install but I didn't notice the icon on the tool bar right away. that's on me... i surmised that the WCS settings were blank. and i was trying to run it over VNC so that was probably not a good thing. more testing to come.
Ah, yes - it needs to be homed. I think it might be possible to check for this. The other thing that I thought of was to check that the spindle was off before probing. Leave it with me and I'll do some checking.
