#linuxcnc-devel Logs

Mar 25 2024

06:59 AM -!- #linuxcnc-devel mode set to +v by ChanServ
07:08 AM -!- #linuxcnc-devel mode set to +v by ChanServ
01:05 PM Unterhaus_ is now known as Unterhausen
01:32 PM Connor: Hey guys.. I've noticed something strange while working in the probe basic GUI.. and tested it out and Axis, and it's doing the same thing. When you have a program that has NO movement, such as a simple spindle warm up, it won't highlight the current line being executed. In fact, it only looks like it highlights actual movements.
01:32 PM Connor: If you are at X0, and your program tells it to move to X0, it won't highlight the line..
01:34 PM Connor: probe basic is using motion_line from status to trigger it.. but I found another called current_line, but it doesn't work either.
01:46 PM rmu: Connor: that's by design of the interpreter -- delineation is blocks with movement, the rest is compressed / folded. for details look at docs and/or source code. also line number and file name has bugs / is misleading if you are calling a macro in another file
01:47 PM Connor: I know about the macros and remap issue.
01:47 PM Connor: But this kinda sucks for programs with long dwells and spindle warm up and stuff.
01:48 PM Connor: what is the difference between current_line and motion_line ?
01:49 PM Connor: and can you provide url for the docs your referring too ?
02:08 PM rmu: https://www.nist.gov/publications/nist-rs274ngc-interpreter-version-3
02:42 PM Connor: I have to say, this feels like a bug more than a feature/by design. Why wouldn't you want the status return which line number you on regardless of weather it's a I/O control, movement, Spindle speed change, or M code or whatever.. If you only want motion, then motion_line, but, I would think current_line would be what ever line it was on regardless.
03:15 PM -!- #linuxcnc-devel mode set to +v by ChanServ
03:27 PM rmu: I think nobody would object if that behaviour is changed
04:20 PM lcnc-relay: <zincboy_ca_on#0> I would certainly applaud changing that behavior. As it is, the gcode view using current_line is pretty much useless if you have lots of remaps or macros going. It is also not intuitive when single stepping that a "step" is between movement lines so multiple lines can be executed in one step if there is no movement.
04:26 PM lcnc-relay: <satiowadahc#0> There is fuzzy logic in the interpreter that attempts to read by blocks vs by line.
04:29 PM lcnc-relay: <zincboy_ca_on#0> On a different note, I have been looking at the (LOG,) behavior and there are a few improvements I have implemented. One is to add the variable expansion to (LOGOPEN,) so filenames can have gcode controlled numeric values inserted. The second is adding a Fanuc style variable expansion formatting feature. For example: (debug,#1) right now would result in 0.000000 in the expansion string. With the added formatting,...
04:29 PM lcnc-relay: ... (debug,#1[40]) would result in " 0" and (debug,#1[53]) would result in " 0.000". The first digit in the square bracket is the number of characters before the decimal place and the second char is the digits after it. This allows much more human readable output.
05:40 PM Connor: I just modified my spindle warm up so that it has .001 movement on the z up an down for each speed change so I know where it's at in the program..
07:26 PM lcnc-relay: <big_kevin420#0> from what i understand, its not easy, the line thing
07:28 PM lcnc-relay: <big_kevin420#0> but i think motion line is the line the interpreter is on, not necessarily the movement you are doing
07:29 PM lcnc-relay: <big_kevin420#0> which can be 1000's of lines ahead of the motion you are doing
09:19 PM -!- #linuxcnc-devel mode set to +v by ChanServ