Basic question about emc threads: is the servo thread just a sub multiple of the base thread?
If so, is the count available for finer scheduling of servo thread synced operations?
all slower thread periods are integer multiples of the fastest thread
I don't know that the multiple is directly accessible, but the thread period is
we know that even if the nominal periods of two threads are K and 10*K that they do not actually run in that strict alternation. tests/threads.0 used to test for this but in 2008 Seb made the test check a weaker condition instead.
one reason for the non strict alternation would be if the servo thread runs for so long that the base thread interrupts it -- the base thread has a higher priority than the servo thread
on real machines the test was fairly reliable, it was in vmware or some other virtualization program that seb saw the test fail
For SPI /DMA/ RTNET or Ethercat basically any interface with some latency it would be nice to pull the trigger on read-request at a particular base thread count
(where instead of read compute write you have to read-request wait read compute write)
well, perhaps you could give rtapi a mode where it only has one rtai thread at the base period rate; if you have two threads at rate K and 10*K then it would call base every time and base followed by servo the 10th time. but if the servo lasts more than K then you might end up in trouble because you'll miss a deadline.
how long a turnaround is it? 10us, or 100s of us?
you could always just busy-wait, but if it's 100us then you busy wait 10% of the time away
Right, you can also just be one sample behind with your read data and run the servo loop faster to compensate
(doing read/write/read-request each time)
For DMA, its probably simplest to just wait (no longer than 10 uSec probably)
For our SPI stuff slowest turnaround would be maybe 20 usec. EThercat or RTNet may get into the 100 uSec region, not sure how efficient their drivers are either
it's too bad I don't know the rtai api very well; I am not sure what's possible -- only that the rtapi layer makes very little easy
ok, how about this. hal will keep track of how many times a thread has been run -- call that number R. With each function you put on the thread, you can specify two numbers A and B; the function actually runs if R%A==B. Default A=0, B=1 so that functions run every time (current behavior)
but you could run with a 100ms thread, specify A=10, B=1 for most things and A=10, B=0 for the 'request read' function
that'd be about the same as running a 1ms servo thread, but you can do your 'request read' activity in advance like you want
so you are calling "request_read" 1 out of 10 runs of the base thread, and invoking the rest of the servo code in the servo thread? that doesn't work
if you are talking about invoking request_read 1 out of 10 runs of base, and the rest of servo _also_ 1 out of 10, but not the same 1, then you are screwed if servo_time + base_time > base_period
(oh, I meant 'run with a 100us thread', of course)
jmkasunich: I am not sure my idea is entirely baked, but I think I didn't make it clear either
yeah, I assumed 100mS was a typo
one thread, 100us (not two threads)
that doesn't work
over 10 invocations, the thread does: read, everything else, then nothing 8 times
so everything happens once per ms but you got the chance to issue the read request 100us early
unless you are absolutely sure that the worst case execution tome of the base code, and the worst case execution time of the servo code, add up to less than the base period - which is probably not true
the reason we have two threads is so that the servo stuff can use several base periods to get stuff done, and the higher priority base stuff interrupts it
yes, if "everything else" takes over 100us then you miss a deadline
(or if "issue read request" does)
everything else DOES take more than 100uS, or at least it certainly can
think of complex kins math - possibly even stuff that has to do successive approximation to home in on a solution because a closed form solution doesn't exist
the idea of scheduling threads at something other than simply "every 1mS" is interesting, but I think we have to retain distinct prioritized threads
in this kind of system I think both 'read' and 'everything else' are the same priority
yes, but both are lower than the base thread
also, "same" is tricky - what happens if read isn't finished when everything else is ready to run?
gotta pick one or the other, hence prioroty
hm, rtai has rt_sleep and rt_sleep_until. "During this time the CPU is used by other tasks"
I wonder if that includes non-realtime tasks...
if so, maybe just try having 'read' request read, rt_sleep, finish read .. if that works out, we can add the call to rtapi which would just pass it through
what does sleep take as an arg? time in nS or something?
it takes an RTIME which is the same as rt_make_task_periodic
rt_sleep(nano2clocks(20*1000)) // sleep (non-busy-wait) 20us
looks like that would eliminate some busy-waiting
scary though, if the user specifies a sleep time that is a significant portion of (or greater than) the task period
in the application that seb has in mind, is the requirement to wait for some specific time interval, or are we waiting for the hardware to do something (which we can detect as finished by reading the hw)?
I assume that there's something you can poll to see if it's done, but I'm not sure
I guess it was PCW, not seb
anyway, he's talking about requesting the data before it's needed, to give it time to arrive
right, I think it's about kicking off some number of SPI reads in advance
the sleep approach would work there, as would busy waiting, or "early start" - early is relative, we can either start the data early or do the computations a bit later, the net result is identical
in any of those cases, the only difference is leaving more CPU cycles for the background non-rt code
is a pc keyboard a grid that's scanned or is it more complicated than that?
I wonder what the overhead of rt_sleep() is
hm, now why in the world did I require that a component have at least one pin?
cradek: since the interface is serial, I think the kb maker is free to do whatever they want
I bet most do some sort of scan/multiplex thing, but I don't think it is standardized
back in the day there were standard scan codes, and I bet they mapped to the actual scan pattern of the IBM kbs, but today it can be anything
I need approximately a 5x10 grid of buttons...
will you press more than one at a time?
then I'm sure you could gut a keyboard and connect your 50 switches in place of 50 of the keyboard's switches
you don't need to care about how the kb does it
if you want to have less than 100 wires soldered to the pcb, then you start caring
it's not for a pc, I actually need a grid of contacts or something to simulate it
are you talking about an input device (100 switches going to a PC or micro or whatever), or an output device (PC or micro or whatever making 50 contacts close)
I foolishly tried to fix the membrane keyboard on the bridgeport
sorry I didn't mean to be mysterious
you tried to fix the membrane, and?
I bet you can guess how that went
it doesn't work at all now
it worked 10% before so this is not much worse, really
and so somehow that leads to a question about how PC keyboards work?
yeah if I had a grid, I'd just label them and it could work enough to home and run a program or two - that's the goal
so the data that I'm missing is that the BP _does_ use a grid, and you are wondering if the switch assy (less the micro) of a PC can be used to replace it
why dincha say so in the first place?
poor communication skills, mostly
do you know the nature of the BP scan? N rows by M columns, with or without diodes in each switch, etc?
I have schematics - I will dig
you could open up a $5 PC keyboard and trace things probably
I'd be astonished if it wasn't some sort of scanned matrix, but the dimensions might be strange
if there aren't diodes at each switch, you can get strange effects if more than one switch is pressed
I know there are no diodes in the keyboard
do you know how many wires connected to the kb (I'm assuming we're talking about the BP kb now)
yes I have the schematic for the keyboard. it is 5 rows, 10 cols
plain old switch closures, no smarts
rt_sleep seems to just return RT_TMROVRN
and the .time of the thread doesn't change when I change the requested sleep time -- but it should since the time is in tscs
yes I think that's what that means
how long of a sleep are you requesting?
20us from a 1ms thread
try requesting 200uS
the only implementation I can think of for rt_sleep would require it to set up a hardware timer to generate an interrupt at the desired wakeup time - that's the only way to get control back from the background task
hm that *does* change the time of the thread
that setup might take non-trivial time, or might conflict with the normal periodic interrupt that is already being used'
er, no, it doesn't. adding more outb()s did.
cradek: imagine 5 rows connected to 5 outputs from a micro, and 10 columns connected to 10 inputs
the columns are pulled up by resistors, and the row outputs are normally high
rows are A-E, cols are 0-9
micro pulls A low, reads inputs, the puts A high and pulls B low, reads, etc
if B3 is closed, then when B is low, 3 goes low - simple
but suppose A5, B5, and A3 are closed
B goes low, which pulls 5 low thru B5, that pulls A low thru A5 (fighting the A output which is trying to hold A high)
assuming that A goes low, that in turn pulls 3 low thru A3
the software sees 3 go low while B is low, and assumes (incorrectly) that B3 is closed
the BP folks may simply have ignored that issue - especially since you don't touch type on such a kb, the odds of three switches being hit at the same time are low
yeah I'm sure the problem is it's got one or more things shorted row-to-column
PC keyboards probably have to take a more sophisticated approach to dealing with that problem
yes I bet it does wrong things if you press more than one key at once (and that's what it's seeing)
RTE_TMROVRN if an immediate return was taken because the delay is too
short to be honoured.
ah, that makes sense
[983985.716836] sysctl table check failed: /dev/parport/parport0/devices/sleeptest/timeslice Sysctl already exists
well that's a new one on me!
this happened during testing rt_sleep()?
yes, but it was an unrelated problem (registered parport but didn't unregister it)
(sleeptest tweaks the parport, then calls rt_sleep, then tweaks the parport again)
well both from the scope and from other indications it's clear that rt_sleep isn't behaving as desired
[ 574.532058] PARPORT: ERROR: port parport0 claim failed
[ 574.532065] parport0: àdÚ߀gÚß tried to release parport when not owner
looks like my simple test code is still wrong :)
seems like a good time for that here too
ho boy, I would have made that announcement on -developers nly
EMC: 03jepler 07master * r329963bc9c39 10/src/po/it.po: Update Italian translation
whee, my menu patch works on 9.04 as well
EMC: 03jepler 07master * r2013d8013b9c 10/scripts/latency-test: make latency-test run without emc-environment
EMC: 03jepler 07master * rb300fd687e85 10/scripts/emc.in: set LD_LIBRARY_PATH like emc-environment
EMC: 03jepler 07master * r992e6bede71a 10/ (6 files in 4 dirs): 'make install-menus' puts RIP in the Applications menu
jepler: rip menus work for me (after I reboot :) )
jthornton: it's enough to ctrl-alt-backspace
or there's another reload signal that can be sent to gnome
but I don't know which one
alex_joni: that will rebuild the menus?
alex_joni: did you see the inkscape plug in on the forum?
ctrl-alt-escape will kill your X server
when it will restart, it'll surely rebuild the menus ;)
yes, I did
huh, the items appeared for me without logging out (both on 6.06 and 9.10)
I was on 8.04 and had to boot
or have the secrect decoder ring from alex_joni
I noticed that if you just 'make install-menu' it didn't create all the necessary files; I had to 'make; make install-menu'
could it have been that?
I put the make install-menu after the make in my script...
then ran the script?
ok, that should be fine..
I'll have to try this myself on an 8.04 machine, but for now a note on that thread that you might have to restart your login to see the items wouldn't hurt
opps I've deleted that email all ready
EMC: 03jepler 07master * rcf28af957cdf 10/tcl/emc.tcl.in: provide tcl with info about config directories
EMC: 03jepler 07master * r078101f485df 10/tcl/bin/pickconfig.tcl: make sure to always describe directory
EMC: 03jepler 07master * r1f6cd76c5c5a 10/tcl/bin/pickconfig.tcl: get config dir list from emc.tcl
EMC: 03jepler 07master * ra570537b044c 10/tcl/bin/pickconfig.tcl: dir is guaranteed to be normalized
EMC: 03jepler 07master * r853d893e600c 10/tcl/bin/pickconfig.tcl: describe directories even for RIP
EMC: 03jepler 07master * rbec97ff71e22 10/tcl/bin/pickconfig.tcl: close right directory even for RIP
EMC: 03jepler 07master * rb83b1e254762 10/tcl/bin/pickconfig.tcl: correctly track whether there are nonsample configs
EMC: 03jepler 07master * r8206287dd8c5 10/tcl/bin/pickconfig.tcl: USER_CONFIG_DIR is a better way to name this location
EMC: 03jepler 07master * r4b911b69b53a 10/scripts/emc.in: don't send a pickconfig argument that goes unused
EMC: 03jepler 07master * r314f3aa2d90e 10/src/emc/task/emctaskmain.cc: improve behavior of MDI O-calls
EMC: 03jepler 07master * ree2d031d70f0 10/.gitignore: make overzealous ignore more specific
EMC: 03jepler 07master * rf40889afa748 10/src/Makefile: make the rule name match what I said in an earlier commit
EMC: 03jepler 07master * r81d7f2a54260 10/src/Makefile: make sure install-menu updates all menu-related files
EMC: 03jepler 07master * r9e03062a872a 10/src/emc/ (6 files in 3 dirs): factor tool table reading out of iotask
EMC: 03jepler 07master * r519fcb2ef1dd 10/src/emc/sai/ (Submakefile driver.cc): use new tool reading code in standalone interpreter
EMC: 03jepler 07master * r5d97897bc6cf 10/src/emc/rs274ngc/tool_parse.cc: fix a warning
EMC: 03jepler 07master * r637610ffbc59 10/src/emc/rs274ngc/tool_parse.cc: parse old-style tool files
EMC: 03jepler 07master * rfb8f8958a6c8 10/src/emc/rs274ngc/tool_parse.cc: warn (on terminal) about unrecognized lines
you fixed sai! yay!
and you fixed it the right way even
PCW_ is now known as PCW
Runtest: 34 tests run, 34 successful, 0 failed + 0 expected
Is the removal of G43.1 I- K- the only gcode incompatibility, or is there something about G10 L1 that is not forward-compatible?
G43.1 I- K- is no longer accepted, but it was in 2.3.
is that the only one, or is there a G10 L1 that was accepted in 2.3 but not anymore?
only paramters on G10 was added
thanks for the tooltable fix :-)
> G43.1 @1 ^1
Polar coordinates can only be used for motion
cradek: awww drat ^^^^^
don't be ridiculous
does this mean my old tool table will get automagically converted?
cradek: yes, I hope so
because if so, that's all kinds of awesome
hmm, I could make G43.1 I- K- work again, but it would be a different meaning in 2.3 for machines that were tlo_is_along_w
(because K would always be applied to Z, not W)
the code's written, but I dunno whether to push the change..
if the behavior changes, breaking the syntax is a feature
(I think I'm serious)
seb_kuzminsky: in this case I'm going to use the master packages on Jr. I don't have any need to compile on it.
the new debs from jeff's fix should be ready in a few minutes :-)
i'm excited to come see you guys tomorrow
but I'm already wishing we had more time!
glad the weather is nice for your drive.
EMC: 03jepler 07master * r3378b866639b 10/nc_files/ (cone.ngc tool-length-probe.ngc): use new g43.1 syntax
yeah it's going to be super rushed...
grump, the buildbot built the wrong thing - it re-built the previous version, since i had forgotten to tell it to clean the build dir
what are you guys having? A mini mesa rumble?
skunkworks: it's a mesa vs bridegeport smackdown
i'm trying to build up the nerve to buy chris' bridgeport & we're going to start by converting it to emc2 :-)
Aww - very cool!
did cradek ever find a transformer to convert the servo drives to single phase?
he's got the transformer, but we'll probably still need some more caps & a new rectifier
we finally started our conversion... http://www.electronicsam.com/images/KandT/conversion/xaxis/stripped.JPG
are those brass pipes the lube system?
skunkworks_: you can drive down if you want
yeah, by all means come join us
I think everyone agrees it's a blooper to have text on icons since it's not localizable. but what about our O words? was it bad to use english words instead of making a bunch of new M codes or something? I think many other controls use the latter system.
programming languages have a long history of having their tokens in english
I suspect more people are better served by "O call" than "M1337"
(I want to argue it's not relevant, since end users don't come into contact with programming langauges, but I can't bring myself to do it)
I suppose if it's an understandable word for half the users and an arbitrary token for the other half, that's better than it being an arbitrary token for everyone
but of course all the rest of gcode is arbitrary tokens...
even I don't care about this, and I brought it up
heh - I don't think I can make it. would be fun though!
EMC: 03jepler 07master * r51a2ee9fd46b 10/src/po/ru.po: Update Russian translation
aystarik: ^^^ thanks, applied.
skunkworks: where do you live?
jthornton: both lathe/lathe-user and gcode/tool_compensation have different diagrams showing the different tool orientation
jthornton: perhaps they should use the same image instead
seb_kuzminsky: I live near lacrosse wi (trempealeau)
long-ish drive ;)
I have question
I would like to home stepper machine on index
I have steppers with encoders (internal loop)
I have isolated index signal from encoders
I would like to use software encoder to emulate it
is it possible?
stepgen doesn't know how to reset position on index, but it seems like you could add that
I think there's no problem except it needs an interested person to work on it :-)
but I don't know (get) why stepgens must reset position of index?
(I never used indexes)
consider a servo homing to index instead
say it's turning at a rate of about 100 encoder counts per ms
the reset-on-index behavior means you know exactly where the index happened
if you don't reset then you know the position within 100 counts instead
that's (one reason) why home-to-index is better than home-to-switch -- you know the position of index to 1 count even if you're moving at more than 1 count per servo period
so to have stepgen "home to index" you have to have the same machinery -- if index-enable is TRUE and the rising edge of index is seen, reset count to 0 and clear index-enable. you have to do the check as often as you issue a step
(so if it's on mesa, you have to change the mesa firmware since that's what issues the steps)
it's interesting that you would home to a particular encoder edge even though your stepper may never be able to settle there
not that that's a problem, but I think it's interesting
mesa had a firmware that allowed stepper homing to index.. I wonder if that ever to integrated.
not that I know of; the hostmot2 regmap text file doesn't name a register for stepgen index
wonder when seb_kuzminsky will stop slapping emc2-buildmaster around
that was on it's own ;)
just to spite you
good night all
see ya micges
i'll stop slapping it when it stops misbehaving
but what about its morale?
did it make a package with the fixed runtests on master yet?
it did for realtime, but not for sim
i just fixed the problem that prevented the sim deb from building and restarted it
was it a divide by zero?
[22:07:37] <alex_joni> http://verydemotivational.com/wp-content/uploads/2010/01/129080056570437982.jpg
Probably for stepgen index you don _not_ want to reset on index, just latch the current count on index
cradek: the most recent deb is from aystarik's localization commit
funny, git describe doesn't work in my master checkout, but it is 51a2ee9
PCW: the hypothetical future hostmot2 could sure latch on index (just like encoder does), but to work with the current homing we'll want it to work "just like" encoder count at encoder index..
cradek: that's because there are no (annotated) tags in the history of master
the driver just uses subtraction to pretend, right?
cradek: git has two flavors of tags, "annotated" and "the one I think you're not supposed to use". guess which one is the default?
cradek: yes pretty much
jepler: well grr
cradek: and even worse, guess which one git-cvsimport created
THE DEFAULT KIND I BET
nah.. the one you're not supposed to use
hey look, it's after 4pm
jepler: seen #emc ?
I was just going to go do anything else!
re step index, Sure Ive thought about it but have not implemented it
you need to finish the retrofit and surprise seb
(dont want to clea counter r, plays havoc with velocity on encoder counters and step sequence on step motors)
cradek: did you init your repo by "git init && git fetch"? If so you dont have tags, and git-describe will choke. If that's it, say "git clone" or "git fetch -t" instead
I just made new annotated tags for all the past v2.x.y releases (in that form) and turned cvs-import into a annotated tag as well
apparently you won't get the latter without 'git fetch -t', but I got the former with my next 'git fetch' in another repo
jepler: your parts are here
is it what we thought we were ordering?
yes, it all looks right
ok, after fetch -t, describe works
oh no, hostmot2 doesn't build on breezy anymore.
/home/jepler/emc2-dev/src/hal/drivers/mesa-hostmot2/hostmot2.h:32: error: parse error before "gfp"
apparently it never would have worked, anyway. When I load it: [11496305.074175] hostmot2: Unknown symbol release_firmware
but that must just be kernel misconfiguration, it's in the headers
would it be wise to change char to int for stepgen for 3.4 ?
jepler: sorry, just read your message on the list
* alex_joni writes "I shall read all channels before saying something" 100 times
hope it's ok to use a Oxxx loop