oh good, numpy does have an OK compatibility layer for numarray, and I was able to find the one thing that wasn't obvious
I am slightly puzzled by a line in dmesg "unknown symbol in module: TPpwm_parse_md"
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.
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?
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
otherwise, it won't be included when the module is built and you'll encounter that sort of error
but it could also be due to a misspelled function name or something like that.
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.
I was going to go to sleep, but can't now!
I know the feeling
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.
I'd just do the a b c amplitudes in case someone wants to do deadzone comp or some such
note the 50% offset for 0 = 512,512,512
Also for a full FOC system the three PWMs = voltages come from the inverse Clarke
but for a simple voltage mode control the may just be R*(theta+-PI/2)
I will start with just ABC, but might elaborate later. There is no reason that it can't have reas
read/write ABC and also write-only phase/amplitude
It could even have trapezoidal step modes, a bit like the stepgens.
Do you have a working bit file?
I do, thanks to that lovely jepler chap
In addition to PWM there's also the fault/ena logic (for device protection current limit)
and the deadzone setup. but these are pretty simple
Yeah, I will look through the regmap and map everyhting once I get the basic structure sorted.
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.
Thats that theory, that it should be easily extensible
Thats the, jeez, time to go home
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?
droppings left by kbuild
kbuild is much stupider than the rest of our build system and we unfortunately can't avoid that mess.
oh, it has different kinds of smarts than our build system :-/
that's a more generous take
Hal-skeleton? Is that a really wacky kinematics module?
no; it is to demonstrate a very basic (skeletal) hal module
is it a problem to start the name of a function, source file or module with a numeral?
Xcode is highlighting oddly
C function names certainly can't start with numerals
source files certainly can
OK, I will be consistent then
I dunno about kernel modules; I don't have any examples that do start with digits.
hal modules created by comp probably have to start with a letter or underscore
EMC: 03jepler 07master * r16078511c893 10/ (2 files in 2 dirs): Merge branch 'i2g-numpy'
EMC: 03jepler 07master * recc9256d212e 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: Revert "Work around a numarray slicing bug (SF#2947390)"
EMC: 03jepler 07master * ra4d991070524 10/debian/control.in: require numpy instead of numarray
EMC: 03jepler 07v2.4_branch * rceb79bc75d37 10/ (2 files in 2 dirs): Merge branch 'i2g-numpy' into v2.4_branch
EMC: 03jepler 07master * rf787468983e5 10/src/emc/usr_intf/axis/scripts/image-to-gcode.py: make i2g work with numpy or numarray
PCW_ is now known as PCW
PCW_ is now known as PCW
in the [EMC] section what are the DEBUG levels?
and what does TASK=milltask do?
grepping the config directory I see two task= in a couple of configs
Sherline4Axis/Sherline4Axis_mm.ini:TASK = milltask
Sherline4Axis/Sherline4Axis_mm.ini:# TASK = minimilltask
and I find this : Sherline4Axis/Sherline4Axis_mm.ini:#- Name of task controller program, e.g., bridgeporttask
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.
is there more than one tast executable?
JT-Dev: in the current time there's only one that makes sense for 99.9% of users, milltask
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
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
ok, thanks I'll put something in the manual for those that want to know
er, earlier I said [EMC]TASK but of course it's [TASK]TASK
historically there were a couple of task controllers, but also different IO controllers
so in the dark days before HAL you had to roll your own task and io controller
for example: bridgeportio used 2 parports and had idea about external estop in/output pins
ugh, the bad old days
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
the first patch looks like a bugfix actually
Mon Sep 17 00:00:00 2001
^^ heh, been holding the patch for quite a while now ;)
I dunno where that date comes from; it's not the authordate or commitdate of the commit objects