#linuxcnc-devel | Logs for 2014-03-31

[10:35:33] <skunkworks> logger[mah]_,
[10:35:33] <logger[mah]_> skunkworks: Log stored at http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-03-31.html
[13:44:27] <andypugh> Silly question: How do I determine what version of LinuxCNC I am running on an installed system (using Touchy).
[13:49:56] <zultron> rpm -q linuxcnc or dpkg-query -l linuxcnc?
[13:56:37] <andypugh> The latter says 2.5.2 which I know isn’t right. It’s definitely a JA3 or JA4 variant.
[13:57:14] <andypugh> (When I say “installed: I mean built from source into /usr )
[13:57:30] <seb_kuzminsky> andypugh: i think there's not a reliable way to tell, in that case
[13:57:52] <seb_kuzminsky> the version number reported is the contents of the VERSION file, which is often not updated by people building by hand
[13:58:36] <seb_kuzminsky> so you have a linuxcnc deb (v2.5.2) installed, and then you ran 'make install' over the top of it, it sounds like
[13:58:39] <andypugh> Anyway, it seems to be easier than I thought, as it looks like I did the build from the Git repo on the machine, not my shared network one.
[13:58:50] <seb_kuzminsky> so you probably have some unknowable mixture of 2.5.2 and whatever you installed
[14:00:24] <andypugh> VERSION claims 2.6.0~pre joints_axes which seems about right.
[14:22:31] <cradek> if you can find the source tree (compare dates with installed files?) git describe will tell you
[16:03:53] <andypugh> Is there a HAL component to convert a U32 to bits? Somone was asking for one to send tool number to a PLC through 4 individual IOs.
[16:04:17] <cradek> andypugh: I do this with classicladder's bitwise math
[16:04:47] <andypugh> I was just about to find the thread and suggest CL as the solution.
[16:04:55] <andypugh> (ie, get rid of the PLC)
[16:05:06] <cradek> heh yes there's also that option
[16:05:23] <andypugh> It could be done with a set of 4 mux_generics :-)
[16:10:41] <cradek> it'd be very easy to write this, but it's also easy to do in CL
[16:14:31] <cradek> if ( !strcmp(tcFonc, "MOY") /*original french term!*/ || !strcmp(tcFonc, "AVG") /*added latter!!!*/ )
[16:15:43] <andypugh> CL source, at a guess?
[16:16:22] <cradek> how did you know?
[16:16:27] <cradek> !!!
[16:16:53] <cradek> anyway, bitwise and is & in CL eval-block speak
[16:16:59] <cradek> fwiw
[16:30:01] <andypugh> Are we allowed to add new HAL components to Master at the moment?
[16:42:02] <seb_kuzminsky> andypugh: yes
[16:42:45] <andypugh> OK, I might do the int to bit thing. It seems like it should exist to complement “weightd sum”
[16:42:55] <cradek> if they're simple comp files with no weird build or packaging process, you can even add them in 2.5
[16:43:21] <cradek> a lot of people have asked for that over the years (and then used CL or wrote it themselves I suppose)
[17:16:55] <andypugh> <feature creep> I guess it ought to have a gray-code option
[17:23:30] <seb_kuzminsky> or just connect it to bin2gray?
[17:26:15] <andypugh> Ah, yes. That saves some work. I had forgotten about that.
[17:33:08] <cradek> it stretches my imagination to think of what a generic bitwise math component would be like
[17:33:25] <cradek> I'd probably write out (a bit) = in1 & in2, and be done with it :-/
[17:35:57] <andypugh> I was just going to have u32 in and (up to) 32 bits out. But I can see arguments for having two inputs and a u32 output for each of and or cor and not.
[17:38:29] <cradek> I thought the whole idea was to get bit outputs
[17:38:44] <andypugh> It is.
[17:39:05] <andypugh> But folk messing about with bits might want to do other stuff too.
[17:39:06] <cradek> which problem are you solving? break a u32 into its component bits? maybe generic bitwise math is a useless sidetrack
[17:39:31] <cradek> yeah it's hard to guess all the potential problems you can solve for people
[17:39:45] <andypugh> It probably doesn’t make any sense to make it part of the same component.
[17:39:58] <cradek> I immediately think of that as a bitwise math problem, but a nonprogrammer probably wouldn't
[17:40:47] <andypugh> But another component to do bitwise ops on u32 might be useful
[17:41:56] <andypugh> (Of course, if you really wanted to you could break up a u32 with the proposed component, individually and/or the bits, and re-assemble with the oddly-names “weighted sum”
[17:41:58] <cradek> bitwiseand could have in1=u32, in2=u32, out1=u32 (in1 & in2), out1=bit !!(in1 & in2)
[17:42:07] <cradek> heh
[17:42:25] <cradek> yeah or you could use classicladder... :-)
[17:42:56] <cradek> bitwiseand with the bit output could do the split-into-bits task with one instance per interesting bit
[17:43:22] <cradek> er I meant out2 of course
[17:44:22] <andypugh> loadrt bitmath personality=8a,32x,2o,16n
[17:45:28] <andypugh> (I wish we could persuade the auto docs to not mention personality when it is used indirectly)
[17:46:39] <andypugh> There are quite a few comps that have to begin with “Ignore the auto-generated synopsis above”
[17:47:55] <cradek> I guess I don't know what you're talking about...
[17:48:04] <cradek> unwanted stuff ends up in the manpage?
[17:48:26] <andypugh> http://linuxcnc.org/docs/html/man/man9/bldc.9.html for example
[17:48:57] <cradek> ha that's very silly
[17:49:49] <andypugh> If you want a comp that has load-time configurable pin layout then you need to use “pesonality”, but often you don’t just want the single int that “personaity” creates as a modparam.
[17:50:05] <cradek> oh my, comp.g is quite the thing
[17:50:20] <cradek> "how hard can it be to fix?", he stupidly thought
[17:51:21] <andypugh> I was intending to experiment with the undocumented “modparam” tag tonight, but I think the plan has changed to “sleeping"
[17:51:52] <cradek> I think after doing bldc, you are our comp wizard
[17:53:06] <andypugh> Jepler did they really clever bit that allows it to generate tables in both manpage and html version.
[17:57:24] <andypugh> neither “modparam” or “include” are mentioned in the manual page. I know that “include” works (you can #include in the C-code section, but sometimes that is too late in the generated C-code)
[18:08:09] <andypugh> I will test “modparam” tomorrow and consider updating the manual page