Back
[00:02:33] <jepler> oh good, numpy does have an OK compatibility layer for numarray, and I was able to find the one thing that wasn't obvious
[00:04:48] <andypugh> I am slightly puzzled by a line in dmesg "unknown symbol in module: TPpwm_parse_md"
[00:05:57] <andypugh> The TPpwm is my first (crude) attempt at support for the Three Phase PWM in Hostmot2. Mainly by copying and pasting the normal PWM code and changing it to suit.
[00:07:01] <andypugh> I am a little puzzled about how the function name is making its way from compiled code to dmesg. I guess that means something somewhere is miss-punctuated?
[00:08:04] <jepler> If it's a new source file, you have to list it in a Makefile. In this case you need to add it to the list of hostmot2-objs in src/Makefile
[00:08:16] <jepler> otherwise, it won't be included when the module is built and you'll encounter that sort of error
[00:08:25] <jepler> but it could also be due to a misspelled function name or something like that.
[00:09:35] <andypugh> Ah! I did wonder how the compiler was meant to find functions in source files with no matching header files. I don't even have anything below Hostmot2 loaded in the project.
[00:10:00] <andypugh> I was going to go to sleep, but can't now!
[00:19:14] <jepler> I know the feeling
[00:21:53] <andypugh> On the subject of Three Phase PWM, I can't decide whether to have the HAL pins just the A, B, C amplitudes directly mapped to the Hostmot registers, or to have Angle-amplitude and put some cleverness in the driver.
[00:42:09] <PCW> I'd just do the a b c amplitudes in case someone wants to do deadzone comp or some such
[00:42:10] <PCW> note the 50% offset for 0 = 512,512,512
[00:46:13] <PCW> Also for a full FOC system the three PWMs = voltages come from the inverse Clarke
[00:46:14] <PCW> but for a simple voltage mode control the may just be R*(theta+-PI/2)
[00:47:20] <PCW> (they may)
[00:49:30] <PCW> (R, Theta+-PI/2)
[00:49:41] <andypugh> I will start with just ABC, but might elaborate later. There is no reason that it can't have reas
[00:50:05] <andypugh> read/write ABC and also write-only phase/amplitude
[00:50:47] <andypugh> It could even have trapezoidal step modes, a bit like the stepgens.
[00:54:40] <PCW> Do you have a working bit file?
[00:55:00] <andypugh> I do, thanks to that lovely jepler chap
[00:55:28] <PCW> Great!
[00:59:41] <PCW> In addition to PWM there's also the fault/ena logic (for device protection current limit)
[00:59:43] <PCW> and the deadzone setup. but these are pretty simple
[01:00:56] <andypugh> Yeah, I will look through the regmap and map everyhting once I get the basic structure sorted.
[01:01:51] <andypugh> Not wanting to jinx myself, but so far it all looks fairly easy. That is mainly because Seb has already done all the hard thinking.
[01:02:41] <PCW> Thats that theory, that it should be easily extensible
[01:03:13] <PCW> Thats the, jeez, time to go home
[01:08:45] <andypugh> Loading my EMC2 source file into Xcode (which I am actually rather liking, though speedis not great down the Wifi to the garage) I see lots and lots of .xxyyzzz.o.cmd hidden files. What be they then?
[01:09:14] <cradek> droppings left by kbuild
[01:09:44] <cradek> kbuild is much stupider than the rest of our build system and we unfortunately can't avoid that mess.
[01:09:56] <jepler> oh, it has different kinds of smarts than our build system :-/
[01:10:47] <cradek> that's a more generous take
[01:11:18] <andypugh> Hal-skeleton? Is that a really wacky kinematics module?
[01:12:22] <jepler> no; it is to demonstrate a very basic (skeletal) hal module
[01:12:38] <andypugh> is it a problem to start the name of a function, source file or module with a numeral?
[01:12:48] <andypugh> Xcode is highlighting oddly
[01:13:01] <jepler> C function names certainly can't start with numerals
[01:13:30] <jepler> source files certainly can
[01:13:31] <andypugh> OK, I will be consistent then
[01:13:45] <jepler> I dunno about kernel modules; I don't have any examples that do start with digits.
[01:13:55] <jepler> hal modules created by comp probably have to start with a letter or underscore
[01:23:22] <CIA-2> EMC: 03jepler 07master * r16078511c893 10/ (2 files in 2 dirs): Merge branch 'i2g-numpy'
[01:23:23] <CIA-2> EMC: 03jepler 07master * recc9256d212e 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: Revert "Work around a numarray slicing bug (SF#2947390)"
[01:23:24] <CIA-2> EMC: 03jepler 07master * ra4d991070524 10/debian/control.in: require numpy instead of numarray
[01:23:24] <CIA-2> EMC: 03jepler 07v2.4_branch * rceb79bc75d37 10/ (2 files in 2 dirs): Merge branch 'i2g-numpy' into v2.4_branch
[01:23:30] <CIA-2> EMC: 03jepler 07master * rf787468983e5 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: make i2g work with numpy or numarray
[03:05:09] <jepler> 'night all
[08:51:33] <PCW_> PCW_ is now known as PCW
[11:01:35] <PCW_> PCW_ is now known as PCW
[11:04:44] <JT-Dev> in the [EMC] section what are the DEBUG levels?
[11:08:25] <JT-Dev> and what does TASK=milltask do?
[11:18:29] <JT-Dev> grepping the config directory I see two task= in a couple of configs
[11:18:33] <JT-Dev> Sherline4Axis/Sherline4Axis_mm.ini:TASK = milltask
[11:18:34] <JT-Dev> Sherline4Axis/Sherline4Axis_mm.ini:# TASK = minimilltask
[11:19:33] <JT-Dev> and I find this : Sherline4Axis/Sherline4Axis_mm.ini:#- Name of task controller program, e.g., bridgeporttask
[11:52:07] <jepler> JT-Dev: [EMC]TASK specifies the name of the "task" executable. "task" does various things, such as communicate with the UIs over NML, communicate with the realtime motion planner over non-HAL shared memory, and interpret gcode.
[11:52:29] <JT-Dev> is there more than one tast executable?
[11:52:46] <jepler> JT-Dev: in the current time there's only one that makes sense for 99.9% of users, milltask
[11:52:56] <JT-Dev> ok thanks
[11:53:33] <jepler> in the dim mists of time (before hal), it was frequently the case that an integrator would have to build a modified version of things like task, io, and motion for a specific machine
[11:56:42] <jepler> debug flags are usually only useful to developers. the meaning of the flags can be found in the source file emcglb.h. in general, entering a value besides "0", "0x0" or the like will cause lots of information to be printed when emc is run in the terminal
[11:57:19] <JT-Dev> ok, thanks I'll put something in the manual for those that want to know
[11:58:18] <jepler> er, earlier I said [EMC]TASK but of course it's [TASK]TASK
[13:21:56] <alex_joni> historically there were a couple of task controllers, but also different IO controllers
[13:24:53] <JT-Work> so in the dark days before HAL you had to roll your own task and io controller
[13:25:48] <alex_joni> yup
[13:26:09] <alex_joni> for example: bridgeportio used 2 parports and had idea about external estop in/output pins
[13:42:18] <cradek> ugh, the bad old days
[13:48:35] <jepler> with this patchset we could get rid of the specifications of TASK and IO in every case that they match the sensible default:
http://emergent.unpy.net/files/sandbox/defaults-for-io-and-task.mbox
[13:54:51] <cradek> yes!
[13:56:27] <alex_joni> the first patch looks like a bugfix actually
[13:57:10] <alex_joni> Mon Sep 17 00:00:00 2001
[13:57:21] <alex_joni> ^^ heh, been holding the patch for quite a while now ;)
[14:21:27] <jepler> I dunno where that date comes from; it's not the authordate or commitdate of the commit objects