Back
[00:43:12] <mhaberler> cradek: to restate the problem in my words: moving current offset/rotation out of interpreters reach breaks position prediction
[00:46:19] <mhaberler> or iow: offset+rotation are conceptually part of interpreter state even if hidden in emcanon.cc and have to be current for correct move generation
[00:50:43] <mhaberler> modifying rotation/offset in motion would imply the interpreter generated commanded positions based on offset/rotation assumptions during readahead which dont hold anymore
[00:51:17] <mhaberler> the only way to get around the problem is syncing after each step which means offset/rotation are always current
[00:51:37] <mhaberler> in my terminology, this is called tainted state:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?QueuebustersRevisited
[00:53:16] <mhaberler> or referring to possibly tainted state (in that case offset/rotation)
[00:57:16] <mhaberler> if this is the case (as it certainly is), then I see how moving canon state cant fix the problem here since you are moving implicit interpreter state
[02:49:02] <KGB-linuxcnc> 03seb 05master 24c5d87 06linuxcnc 10docs/src/Submakefile * docs: fix a source syntax highlighting bug
[08:32:24] <cradek> cmorley: jepler is going to try to figure out what happened with git
[08:33:02] <cradek> your commit 13a2765 is in the server's repo, and I got the mail too (which is how I found the commit) but it is not contained in any branch
[08:33:15] <cradek> this means someone did a push --force and nuked your changes
[08:33:31] <cradek> it may or may not be possible to tell who did it
[08:37:17] <jepler> it looks like it was me :-/
[08:37:29] <cradek> oops
[08:37:43] <jepler> origin/master does not contain 10ef032
[08:37:47] <jepler> origin/master contains ccbef9c
[08:38:20] <jepler> going down the history of commit e-mails that is the last one which does not appear in master, and the first one which does
[08:40:22] <jepler> I'll fix it
[08:40:40] <cradek> thanks!
[08:42:58] <jepler> I wonder whether I used "git push -f" without thinking about the consequences, or whether I somehow have a misconfigured git
[08:43:02] <jepler> I wonder which I'd rather believe.
[08:45:44] <KGB-linuxcnc> 03nieson 05master 4b25372 06linuxcnc 10share/ 10gscreen/skins/gmoccapy/gmoccapy_handler.py 10gscreen/skins/gmoccapy/release_notes.txt * gmoccapy_0_9_7_5_1 - corrected the version number in handler file
[08:45:44] <KGB-linuxcnc> 03jepler 05master 7de0cfb 06linuxcnc 10src/emc/ 10rs274ngc/interp_array.cc 10rs274ngc/rs274ngc_interp.hh * Revert "interp: avoid violating Python runtime contract"
[08:45:50] <KGB-linuxcnc> 03russell 05master 5aac98c 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * STEPGEN_MAXVEL patch
[08:45:56] <KGB-linuxcnc> 03chrisinnanaimo 05master 71f6326 06linuxcnc 10src/emc/ 10motion/control.c 10motion/mot_priv.h 10motion/motion.c * motion -add spindle veloity pins with absolute output
[08:46:03] <KGB-linuxcnc> 03chrisinnanaimo 05master 25b607c 06linuxcnc 10src/emc/kinematics/tc.c * trajectory planner -Don't use feed override in rapids
[08:46:10] <KGB-linuxcnc> 03chrisinnanaimo 05master 864862c 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -add missing INI substitution in HAL file
[08:46:17] <KGB-linuxcnc> 03chrisinnanaimo 05master 7f3ada4 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -fix blank abs and lowpass HAL commands
[08:46:23] <KGB-linuxcnc> 03chrisinnanaimo 05master 13a2765 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -use motions need absolute spindle veelocity pins
[08:46:30] <KGB-linuxcnc> 03chrisinnanaimo 05master d3cb2c1 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -use an absolute spindle cmd pin if minlimit is 0
[08:46:37] <KGB-linuxcnc> 03nieson 05master 10ef032 06linuxcnc 10share/ 10(13 files in 9 dirs) * gmoccapy_0_9_8 - new error messaging system
[08:46:43] <KGB-linuxcnc> 03jepler 05master bd069fb 06linuxcnc * Merge commit '10ef032'
[08:46:50] <jepler> cradek:
http://feeding.cloud.geek.nz/posts/keeping-log-of-branch-updates-on-git/
[08:47:10] <jepler> cradek: if you make this setting on the server, we'll have better information the next time this mistake is made.
[08:47:41] <cradek> slick, will do
[09:07:14] <mhaberler> cradek:
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-10-10.html#05:27:58
[09:23:51] <cradek> mhaberler: I read back. I think you might have it.
[09:24:00] <mhaberler> ok
[09:24:45] <cradek> I bet allowing rotation change during pause is unnecessary
[09:24:52] <mhaberler> yes
[09:25:09] <mhaberler> my next question would have been: is it offset, or just rotation
[09:25:11] <cradek> I am not sure if that simplifies the fundamental problem (it surely simplifies incidental problems)
[09:25:46] <mhaberler> well first its a way how to think about it; if it can be reduced to position prediction yes/no
[09:26:38] <mhaberler> that is also the gist with the queuebusters:
http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_queuebusters_break_position_prediction
[09:27:40] <mhaberler> rotation for sure is
[09:27:58] <cradek> is what?
[09:28:11] <mhaberler> changing rotation during pause
[09:28:18] <mhaberler> breaks position prediction
[09:28:29] <mhaberler> because interp state isnt synced
[09:29:26] <mhaberler> it might be called CanonConfig_t.xy_rotation but its conceptually setup_struct.xy_rotation
[09:31:31] <cradek> you know, I suspect moving ONLY tool offset is both easier and sufficient
[09:31:40] <mhaberler> oh absolutely
[09:32:24] <mhaberler> my question is: will offset ONLY break position prediction (it will break readahead time limits checking but that is easier to deal with)
[09:32:46] <cradek> I don't understand what you are asking
[09:33:16] <mhaberler> let us assume rotation cannot be changed after readahead completes (i.e. during pause).
[09:34:38] <mhaberler> will changing an offset during pause invalidate any later canon commands already in the queue
[09:34:48] <mhaberler> that is what I'm not sure about
[09:35:01] <cradek> yes if you are talking about canon calls as we know them today
[09:35:37] <mhaberler> lets assume this rotate_and_offset has been split into rotate (in canon) and offfset (in motion)
[09:35:58] <cradek> STRAIGHT_FEED(1,2,3) is invalid if you consider G1 X1 Z3 / [change offset now] / G1 Y2
[09:37:13] <mhaberler> do we need to change coordinate sys offsets or just tool offsets? I would think the latter is what would make people would happy
[09:38:03] <mhaberler> didnt come out as a sentence ;)
[09:38:21] <cradek> well people often use them interchangeably. but if it was only tool it might be sufficient to allow the necessary functionality of replacing a tool during pause.
[09:38:44] <mhaberler> well thats the major use case I would think
[09:39:23] <mhaberler> that was probably another misunderstanding about 'moving offset application' - I was unclear; I mean tool offsets
[09:39:35] <mhaberler> the generality of coord sys offset changes IMO isnt needed
[09:41:34] <cradek> I think it might work to do tool offsets in the way I proposed, with two poses stored in motion, the currently active offset for each axis, and the proposed new offset that comes into effect for each axis at the right time (when that word is programmed) if you have the new information with the canon call about which words are programmed.
[09:43:35] <mhaberler> I dont understand your plan yet; 'currently active offset' is the current tool offset?
[09:43:47] <cradek> you could perhaps allow G10 L1/10/11 without Q/R/I/J (axis words only) and move tool offset handling
[09:43:57] <mhaberler> right
[09:44:44] <cradek> do you understand how you could have X and Y affected by mismatched tool offsets?
[09:45:11] <mhaberler> give an example, I claim MBA rights
[09:45:13] <cradek> G43H1 / G1 X0 / G43H2 / G1 Y0
[09:46:41] <cradek> this situation probably happens every time you make an entry move, consider a lathe entry of a drill where you load the drill, then move to X0, then to Z0 and then drill along -Z
[09:47:17] <cradek> between the two moves X is offset by the new TLO and Z is offset by the previously-active-in-Z one
[09:47:28] <mhaberler> I see
[09:48:16] <mhaberler> what about this middle ground: let us think if there is a way to flag constructs which would break if tlo change during pause were enabled
[09:48:20] <cradek> that's why you need to separate currently-active for each axis and proposed-will-come-into-effect-if-the-axis-is-programmed for each axis
[09:48:44] <cradek> what do you mean by constructs?
[09:49:04] <mhaberler> well for instance the sequence you just gave
[09:49:31] <cradek> well I think with this design it doesn't break, and if it does, the design is invalid
[09:50:16] <mhaberler> oh now I'm starting to actually get it.. sure.
[09:52:03] <mhaberler> backing up: so we do agree rotation change during pause wont be supported, and changing of the current tool's offset only - is that what you are thinking of to?
[09:52:15] <mhaberler> too
[09:53:46] <cradek> now I'm wondering if "current tool's offset" is the right way to think about it
[09:55:00] <cradek> I think it is, but as an aside, changing other things in the tool table doesn't matter does it?
[09:55:54] <mhaberler> like orientation?
[09:56:12] <cradek> oh I meant other tools' lengths
[09:56:18] <mhaberler> oh ok
[09:56:24] <cradek> changing orientation is the same problem as changing diameter and I don't think it can be allowed
[09:56:29] <mhaberler> right
[09:57:01] <cradek> and the angles are not currently used by motion, but you don't want to let them change either, for the future when they are used
[09:58:16] <mhaberler> what happens now if somebody changes a random tool table while the interp is running - I guess it reads the current tool table to fetch the current tlo etc
[09:58:27] <mhaberler> I mean some tool table entry
[09:58:43] <cradek> no, you must send the "load tool table" nml message to get it reread, and you can only do that in manual mode
[09:59:23] <mhaberler> so the table is frozen during an auto run
[09:59:50] <cradek> yes I think, except if a G10 changes and writes it
[10:00:02] <mhaberler> well right, but then the interp is in the loop
[10:00:16] <cradek> G10 can change the active tool table and it immediately writes it out
[10:00:30] <mhaberler> I was looking at if there are ways how tt and interp view can get out of sync
[10:01:21] <cradek> interp has a copy of it in memory, and can be told to reread from the file with the nml message, and interp writes it upon any commanded change
[10:01:41] <cradek> well task keeps it, but same difference
[10:01:54] <cradek> there are copies of it everywhere :-/
[10:01:57] <mhaberler> so: down to: no rotation, no G5x changes, Tool axes offset only - no attributes which impact curve shape
[10:01:59] <mhaberler> amen
[10:02:48] <cradek> G5x/G92
[10:03:04] <mhaberler> yes
[10:04:04] <cradek> I think this two-tlo-pose design would actually work if given those canon-gets-which-words-are-programmed changes
[10:05:10] <mhaberler> is that where the NULL value comes in?
[10:05:13] <cradek> the interp would no longer need access to the tool table?
[10:05:35] <mhaberler> hm dia
[10:05:44] <cradek> yes that would be one way to pass that info
[10:05:49] <cradek> oh yeah, it needs that
[10:05:59] <cradek> dia/orientation
[10:06:12] <mhaberler> right, the shape stuff for crc
[10:06:30] <mhaberler> but tlo might drop out of the pciture
[10:06:41] <cradek> seems like it could
[10:07:10] <cradek> have you noticed that tlo is the only one that applies in a predictable direction in motion (it doesn't rotate)
[10:07:24] <mhaberler> ah..
[10:07:51] <mhaberler> so one less dep, meaning rotation need not be carried forward
[10:08:15] <cradek> yes if we don't change any of that working stuff, all the better, it is very intricate
[10:09:04] <mhaberler> well there is one TLO pose already passed to motion, but its really output-only, and nothing happens with it in motion
[10:09:20] <jepler> total aside: You could preserve the current CANON C API if you passed NaN instead of converting to pointers and passing NULL
[10:09:35] <mhaberler> whoa
[10:09:37] <jepler> though client-side changes would be needed either way
[10:09:43] <cradek> or a bitmask!
[10:09:46] <jepler> it's probably a bad idea
[10:09:56] <cradek> well pointers are a bad idea too
[10:09:58] * jepler goes back to $DAY_JOB
[10:10:04] <mhaberler> well the nice thing about protobuf is it allows optional fields so you get that for free
[10:10:10] <jepler> C API
[10:10:12] <jepler> C API
[10:10:13] <jepler> C API
[10:10:14] <jepler> sorry, I'm done now
[10:10:22] <mhaberler> even in the C API
[10:10:36] <jepler> I understand that protobuf has a C API
[10:11:33] <jepler> but I don't think I want the argument to STRAIGHT_FEED to be a protobuf
[10:11:41] <mhaberler> the primary one is C++, which isnt suitable for RT; nanopb works just fine in-kernel and has the same feature set as C
[10:11:53] <mhaberler> why not - it would be end to end
[10:12:16] <mhaberler> no, the arguments would be optional fields
[10:12:30] <mhaberler> which is where the current canon api cant do it without a mask
[10:12:47] <jepler> will you write for me what the declaration of the C function STRAIGHT_FEED would be?
[10:13:09] <jepler> (if it used this facility of protobuf)
[10:13:25] <mhaberler> sure
[10:14:20] <mhaberler> if you want to retain the current api with say a pose or a list of doubles passed in and some of them are optional, then we need to add a set/mask to tell the encoding below which ones count
[10:14:44] <mhaberler> I will use a Python example
[10:14:47] <mhaberler> or C
[10:14:49] <jepler> No, please use C
[10:14:53] <mhaberler> ok
[10:15:19] <mhaberler> are you looking at the canon side (c++) or the motion side (c)
[10:15:40] <jepler> extern void STRAIGHT_FEED(int lineno,
[10:15:40] <jepler> double x, double y, double z,
[10:15:40] <jepler> double a, double b, double c,
[10:15:40] <jepler> double u, double v, double w);
[10:15:44] <mhaberler> ok
[10:15:46] <jepler> we presently have this
[10:15:48] <mhaberler> heard you
[10:15:50] <mhaberler> sure
[10:15:55] <jepler> and we might change it to double * or add a int mask parameter
[10:16:01] <mhaberler> right
[10:16:06] <jepler> or we might change it radically to protobuf and I don't even know what that would look like
[10:16:17] <mhaberler> ok
[10:16:30] <cradek> adding a mask seems super easy
[10:16:40] <jepler> sure, you just insert ", int mask"
[10:16:56] <jepler> and inside the function you write if(mask & AXIS_MASK_X) // do something with parameter x
[10:17:38] <mhaberler> yes, thats exactly. btw we dont need protobuf to do that; we can add a mask to NML just alike
[10:17:51] <mhaberler> but I'll cook an example
[10:17:56] <cradek> I think you'd mostly just pass it on unexamined to motion, and motion (also C) would finalize the enpoints
[10:18:03] <mhaberler> yes
[10:18:20] <jepler> axis/gremlin will have to examine it
[10:18:50] <cradek> are you sure? can't they just ignore tlo?
[10:19:16] <cradek> currently don't they have to subtract it back out to get the preview in the right place?
[10:19:25] <jepler> they will have to deal with unspecified axes by copying the prior value or whatever
[10:19:43] <cradek> oh right, sure
[10:20:00] <jepler> bbl
[10:21:27] <mhaberler> cradek: that was a lot today, let's have it sink in a bit and continue some other time (note I understood what you meant by going to sleep ;)
[10:44:51] <seb_kuzminsky> linuxcnc-build: force build --branch=joints_axes3 checkin
[10:44:52] <linuxcnc-build> build #1386 forced
[10:44:52] <linuxcnc-build> I'll give a shout when the build finishes
[10:49:03] <seb_kuzminsky> cradek, jepler: at work we have a git hook that disallows non-fastforward updates of our stable branches
[10:49:37] <seb_kuzminsky> unofficial branches, feature branches, personal branches etc, can all still be nopn-fastforwarded
[10:50:20] <seb_kuzminsky> i dont know if it's worth it for us to add something like that to our repo, this doesnt seem like a big problem in reality, though it's scary and annoying when it happens
[11:03:44] <cradek> I think we've used --force more frequently to fix problems than to cause them
[11:05:10] <cradek> I guess I'm leaning toward 'just be careful'
[11:05:40] <cradek> everyone screws up once in a while and we can always just fix it
[11:05:42] * cradek shrugs
[11:11:21] <seb_kuzminsky> sounds fine to me
[11:13:27] <jepler> I have a habit of doing --force pushes on my private branches, and it must have spilled over into pushing to the master branch :-/
[11:14:53] <seb_kuzminsky> why do you use so much force jepler ?
[11:15:16] <jepler> because I can rebase out more of the stupid that way, before merging it to master or whatever
[11:17:45] <jepler> this particularly goes for stuff like the complier flag mumbo jumbo, where I need to know what buildbot thinks of the change (so I can't just keep it local or on my private git)
[11:19:46] <seb_kuzminsky> standard rebase activity, makes sense
[11:33:21] <seb_kuzminsky> uh-oh, the wiki formatting docs have disappeared!
http://www.usemod.com/cgi-bin/wiki.pl?TextFormattingRules gives me a blank page
[11:37:22] <cradek> sigh
[11:39:51] <jepler> http://web.archive.org/web/20130811193121/http://www.usemod.com/cgi-bin/wiki.pl?TextFormattingRules
[11:49:49] <seb_kuzminsky> brewster kahle ftw
[12:07:28] <linuxcnc-build> Hey! build checkin #1386 is complete: Success [3build successful]
[12:07:28] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1386
[12:45:56] <seb_kuzminsky> linuxcnc-build: force build --branch=master docs
[12:45:57] <linuxcnc-build> build #1071 forced
[12:45:57] <linuxcnc-build> I'll give a shout when the build finishes
[13:00:44] <mhaberler> here:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=commitdiff;h=8fd37fa147721e5cfe8124b3101ff936016afed6
[13:01:25] <mhaberler> a related python example would be this:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/protobuf/support/encdec.py;h=fa5b8a3ade8f95b737f27127359624fe55217e1f;hb=8fd37fa147721e5cfe8124b3101ff936016afed6
[13:01:27] <linuxcnc-build> Hey! build docs #1071 is complete: Warnings [8warnings compile]
[13:01:27] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1071
[13:02:10] <mhaberler> a RT component en/decoding a protobuf message is here:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/hal/msgcomponents/pbring.comp;h=ac9e318e5c82962cb003d05df8d8f5d8bc434e61;hb=8fd37fa147721e5cfe8124b3101ff936016afed6
[13:02:44] <mhaberler> this messages would travel from userland, or between rt comps if one would like, over Pavel's ringbuffers
[13:03:34] <mhaberler> the protobuf message defs are in src/protobuf/proto
[13:04:13] <mhaberler> all C++,C, nanopb (for RT) and Python bindings fluff is autogenerated from those
[13:06:46] <mhaberler> the JSON and TextFormat representations come automatically as well, both directions: from/to
[13:08:28] <mhaberler> the plain proto-c C bindings libs are currently generated as well, but I dont use them because they are much more error prone in use than both the C++ and nanopb stuff
[13:09:11] <mhaberler> thanks to textformat, message stream recording and reply comes free, too
[13:09:44] <mhaberler> the only stuff I'm still lacking is a Wireshark decoder plugin
[13:12:05] <seb_kuzminsky> linuxcnc-build: force build --branch=v2.5_branch docs
[13:12:05] <linuxcnc-build> build #1072 forced
[13:12:06] <linuxcnc-build> I'll give a shout when the build finishes
[13:13:36] <seb_kuzminsky> most recent docs from the buildbot get pushed here now:
http://www.linuxcnc.org/stage-docs
[13:13:57] <seb_kuzminsky> one dir for master, one for v2.5_branch, and everything else goes in scratch
[13:17:03] <seb_kuzminsky> jepler: if it looks good (and i think it does, now), we should make w.l.o/docs point to the new place
[13:22:25] <mhaberler> on the receiving side, you'd test for a optional field being present by if (msg,has_<fieldname here>())
[13:28:58] <mhaberler> bbl
[13:35:30] <linuxcnc-build> Hey! build docs #1072 is complete: Warnings [8warnings compile]
[13:35:30] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/docs/builds/1072
[15:39:13] <KGB-linuxcnc> 03seb 05master 29582c3 06linuxcnc 10docs/src/gcode/overview.txt * docs: rebranding
[15:54:15] <jepler> seb_kuzminsky: it needs indexes like the old one..
[15:54:39] <jepler> it needs the older docs back to v2.0_branch (a copy of the old docs)
[15:56:29] <seb_kuzminsky> i think we should re-use the current index and the current copies of the old docs
[15:57:12] <seb_kuzminsky> err, somehow
[15:57:21] <jepler> I agree
[15:57:30] <seb_kuzminsky> JT_Shop: are you around? i have a question about docs...
[15:57:44] <jepler> seb_kuzminsky: It sounds like we will need to provide users solid documentation on what
[15:57:47] <jepler> operations invalidate Python component objects.
[15:57:50] <jepler> errrr
[15:57:56] <jepler> seb_kuzminsky: I put in ~emcboard: docs-20131010.tar.gz
[15:57:59] <seb_kuzminsky> jthornton: hello?
[15:58:04] <jepler> play mix and match
[15:58:26] <seb_kuzminsky> jepler: thanks
[16:00:56] <JT_Shop> seb_kuzminsky, for a few minutes more
[16:04:43] <seb_kuzminsky> oh hey!
[16:05:20] <seb_kuzminsky> it looks like gcode/mill_canned.txt is no longer used, i think you moved its contents to gcode/gcode.txt in commit 95152807010091d8abf83498fe6dc2f15aace6c5
[16:05:23] <seb_kuzminsky> does that sound right?
[16:05:34] <seb_kuzminsky> and if so, should we remove mill_canned.txt?
[16:05:50] <JT_Shop> that sounds correct, I wonder why I didn't delete it?
[16:06:20] <seb_kuzminsky> you liked it so much you couldn't bear to remove it?
[16:06:37] <JT_Shop> or more like I got distracted and forgot
[16:07:55] <JT_Shop> I just looked and yea I moved all that to gcode.txt
[16:08:56] <JT_Shop> thanks for catching that
[16:10:30] <JT_Shop> gotta run now
[16:15:19] <seb_kuzminsky> ok thanks! i'll remove it
[17:32:37] <KGB-linuxcnc> 03seb 05master e5a9b7c 06linuxcnc 04docs/src/gcode/mill_canned.txt * docs: remove an obsolete file
[18:09:14] <JT_Shop> yea
[21:28:49] <cmorley> Jepler: Thanks for looking into it and fixing the commits - I thought i was losing it for awhile :)
[22:16:40] <cmorley> oh and helping with gscreen packaging make file magic a while back... and RTAI fixs so PNCconf tests worked better...
[22:18:50] <jepler> cmorley: no, it turns out to have been all my fault
[22:18:58] <jepler> and you're welcome
[22:19:08] <jepler> keep up the good work on your end, I'll try not to delete it.
[22:19:30] <cmorley> lol too funny :)
[22:47:31] <KGB-linuxcnc> 03chrisinnanaimo 05v2.5_branch 2493a7d 06linuxcnc 10src/emc/ 10usr_intf/pncconf/pncconf.glade 10usr_intf/pncconf/pncconf.py * pncconf -add bit and word memory options to classicladder
[22:52:04] <KGB-linuxcnc> 03andy 05master 25f1203 06linuxcnc 10src/hal/components/ 03bin2gray.comp 03gray2bin.comp
[22:52:07] <KGB-linuxcnc> Add a couple of HAL components to convert to and from Gray code
[22:52:10] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[22:52:21] <KGB-linuxcnc> 03andy 05master b1ec930 06linuxcnc 10src/hal/components/gray2bin.comp
[22:52:23] <KGB-linuxcnc> I forgot that sim has no idea what an unsigned int is.
[22:52:26] <KGB-linuxcnc> Luckily I don't actually care if I end up with 64 bits.
[22:52:29] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[22:52:42] <KGB-linuxcnc> 03russell 05master 92f7796 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * STEPGEN_MAXVEL patch
[22:52:48] <KGB-linuxcnc> 03chrisinnanaimo 05master 50ca45a 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -add missing INI substitution in HAL file
[22:52:55] <KGB-linuxcnc> 03chrisinnanaimo 05master 7fd33fa 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * pncconf -fix blank abs and lowpass HAL commands
[22:53:01] <KGB-linuxcnc> 03chrisinnanaimo 05master 2493a7d 06linuxcnc 10src/emc/ 10usr_intf/pncconf/pncconf.glade 10usr_intf/pncconf/pncconf.py * pncconf -add bit and word memory options to classicladder
[22:53:09] <KGB-linuxcnc> 03chrisinnanaimo 05master d87f08b 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py * Merge branch 'v2.5_branch'