Back
[14:42:50] <skunkworks> pcw_home, if the idrom says Module 4: PWMGen, version 0 [instances=6]
[14:43:50] <skunkworks> does that mean that the pinout is setup as the 7i48?
[14:45:12] <skunkworks> so pin 23/25 would be the first pwm?
[14:45:24] <micges> no, that info is shown on pinout section
[14:45:51] <micges> hmm mesaflash doesn't show pins iirc
[14:47:39] <skunkworks> heh - not that it is a big deal - with the version of linuxcnc that I am running - I don't know how to get the pinouts. (and I am just playing)
[14:56:15] <micges> hold on
[14:58:55] <micges> skunkworks: loadrt hostmot2 debug_modules=1 debug_module_descriptors=1 debug_idrom=1
[14:59:12] <micges> skunkworks: should show enough information
[15:00:19] <linuxcnc-build> build #537 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/537 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:03:30] <andypugh> err, what?
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/537/steps/compile/logs/stdio
[15:05:15] <linuxcnc-build> build #1336 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1336 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:05:59] <cradek> +license "GPLv2+";
[15:06:13] <cradek> I think you can only say "GPL" in that spot, because that string is special to the kernel
[15:06:14] <skunkworks> http://pastebin.com/Z1iuvW8W
[15:06:23] <andypugh> Ah damn and blast
[15:07:04] <andypugh> I spent quite some time looking back through emails looking for the list of "allowed" strings but failed to find it.
[15:07:07] <jepler> see the manpage for MODULE_LICENSE in master
[15:07:23] <jepler> The string "GPL" is interpreted by the kernel to mean "GPL Public License v2 or later"
[15:07:30] <linuxcnc-build> build #1333 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1333 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:07:33] <jepler> "GPLv2+" is an unrecognized string, which causes the module to be treated as proprietary
[15:08:14] <linuxcnc-build> build #1332 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1332 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:08:23] <jepler> I wrote this in the comp documentation when I became aware of this linux kernel convention:
[15:08:26] <jepler> license "GPL"; // indicates GPL v2 or later
[15:09:56] <jepler> so anyway the string itself you need to change back to just "GPL", your call on whether to add a comment that elucidates what the documentation tells you about the interpretation of that string by software...
[15:11:26] <skunkworks> bbl
[15:33:02] <linuxcnc-build> build #1331 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1331 blamelist: Andy Pugh <andy@bodgesoc.org>
[19:04:08] <micges> andypugh: skunkworks: pcw_home: rtai port of 7i80 driver is still dead end :|
[19:05:29] <andypugh> Bah! Why?
[19:06:35] <andypugh> (Maybe I mean "how" or "in what way"). And I thought English had too many ways to ask questions.
[19:08:00] <micges> this time I get to compile and run driver, and even my 'fancy hell' init function what is all about runs properly
[19:08:32] <micges> but I have now recv timeouts, often garbage i sended / returned
[19:09:10] <micges> even once INIT led onboard light up, it means packet processing error
[19:10:16] <micges> same setup on xenomai works many hours
[19:10:59] <micges> I need rtnet expert :)
[19:14:34] <andypugh> Maybe it is something that can be fixed at the Mesa end?
[19:15:10] <andypugh> And I guess you have considered the possibility that you are already the world expert in rtnet?
[19:17:49] <micges> hah
[19:18:46] <micges> only if it were little more pleasant to dig in into rtai :)
[19:20:36] <andypugh> I think you need to get some interaction with PCW. It is entirely possible that the 7i80 is sending garbage.
[19:21:04] <micges> no
[19:21:20] <micges> INIT led indicated that garbage is sended into 7i80
[19:21:55] <micges> under rtai, even if it work under xenomai
[19:24:18] <andypugh> Well, hopefully running a Xenomai config won't be a problem in the next release
[19:25:16] <micges> seems so, ub is working quite well
[19:29:23] <andypugh> I winder when we will reach the cut-off for 2.6?
[19:30:40] <micges> there is no plan
[19:31:05] <andypugh> I think there is possibly a bit of a plan.
[19:31:21] <micges> and I also need fix ja3 teleop wheel jogging
[19:32:04] <andypugh> I have decided that my tooltable stuff is 2.7.
[19:32:38] <andypugh> But I have also decided that your ja3 jogging is 2.6. SOrry you couldn't make the meeting. :-)
[19:33:25] <andypugh> (More seriously, it would be nice to have wheel jogging if Ja3 is going mainline)
[19:34:10] <micges> it will
[19:34:11] <andypugh> And I do already have a branch that supports infinite tools, perhaps I ought to see if I can make a stabe half-ay-house
[19:34:30] <micges> ja3 is going into master
[19:35:30] <micges> what is your tooltable work?
[19:49:52] <andypugh> The tool table as a database. Rather than being inside an NML message, anything that wants to know about a tool queries a database.
[19:50:56] <andypugh> We need a lot more queue-busting, but frankly the current code is far too unwilling to throw away the motion queue.
[19:53:15] <andypugh> It is an idea that grew in scope, but the current structure supports a whole-factory database, with machines aware of what tools they have available, and they might choose any of a dozen 8mm end mills that exist in the database. (and will use the wear offset that was applied by the operator when it was on a completely different machine)
[19:53:44] <micges> nice
[19:54:44] <andypugh> it does mean that I end up moving nearly all of iocontrol into user-configurable userspace HAL modules.
[19:55:23] <andypugh> So, there is a lot of work to be done to create a robust default system that emulates the status-quo.
[19:57:24] <andypugh> I had a few months off actually working with machines, and then reconfigured my build-environment (git repo on the Mac, not the DN2800) and decided to take on a simple HAL module job to get back in to coding and to iron out the environment bugs. But the HAL module (serial encoders) has grown and grown.
[19:58:19] <micges> hah, simple :)
[19:58:54] <micges> what hardware do you have to test?
[19:58:57] <andypugh> Tonight I have been working on the Phase-locked-loop that Pete invented to pre-trigger the serial encoders so that the data is as current as possible when read.
[19:59:20] <andypugh> I have an SSI laser rangefinder. :-)
[20:00:08] <andypugh> 140m range, 1mm resolution. But it was the cheapest SSI device on eBay that day (£50)
[20:00:52] <andypugh> I can't think of any use for it when I have finshed, though.
[20:03:10] <micges> sell on ebay :)
[20:03:23] <micges> for 45
[20:03:51] <micges> btw I've setup 7i76E board
[20:04:18] <micges> minor changes to mesaflash and driver (names only)
[20:04:41] <micges> can't wait for 7i77E :)