hi there :-)
When you checked the basethread issue with HostMot2s stepgen how did you create the base thread?
are you asking how to create multiple threads, or what his setup was like? (I can answer only one of those questions :) )
i used a config that someone sent me that had the basethread
i think it was made with pncconf
Oh ok its the pncconf configs where the problem first showed up
Still a mystery I guess here are 2 of Ricks halscope log files:
[21:23:33] <PCW> http://filebin.ca/rhadc
[21:23:35] <PCW> http://filebin.ca/nfyys
These are for forward and reverse motions with base thread enabled (showing the error)
is this with 2.4.2 or with an older version?
I think 2.4.1
i fixed some bugs at the cnc workshop that may be related to this
the fixes went into the 2.4.2 release
ISTR you were never able to duplicate the problem
i was not, but i was able to reproduce a different problem that may be related - small motion errors that only showed up when moving in the negative direction
I just cant figure what the base thread has to do with anything (other than maybe adding more jitter to the servo thread)
PCW: i agree, especially since the pncconf base thread was empty...
i'm currently thinking it's a coincidence
Well both C. Morely and Rick G have the problem when a basethread is present and i t goes away when the basethread is removed
(both with pncconf generated HAL files)
check the actual timing of the threads. the servo thread will be the largest multiple of the base thread that is not longer than the requested period
the base thread period becomes the timing "chunk", rather than whatever timer is used
Three base thread timings were tried (looking at Ricks .ini file)
50 uSec, 150 uSec and 300 uSec, all caused trouble
( the 50 uSec should have not changed the requested 1 mSec servo thread
if 50 caused trouble, then I would expect 150 and 300 to do so as well (since you can't even get close to 1000 with an integer multiple of 150 or 300)
yes, it might
if the timing source can't do exactly 50 uS, then something close will be chosen, say 48.9
the closest you can get to 1000 with 48.9 as your resolution is 978
(without going over)
that's a lot worse than ~998.9, which it might be if the servo thread were the only one
(those numbers are bogus, and just used for illustrative purposes)
in any case, that's the only other thing I can think of at the moment which would be different between a setup with an empty base thread and one with no base thread
the other one is what you identified, that latency/jitter may be different
So the question now is what number the HM2 stepgen uses for its calcs, the 1 mS or 998.9 uSec
I dont think the HM2 stepgen feedback loop has an integral term to fix timebase differences (which would not exist in the software stepgen since it has only one clock)
hm2 uses the reported thread period in its calculations
I believe that the "period" value passed to functions is the actual thread period (in RT anyway, there's an option in sim)
i think this time is the actual thread time used by hal/rtai
thread period, not thread time
and it isn't compensated for other functions in the thread that may have varying execution times (not that it should matter much)
or for latency
PCW: do you have any actual copies of these problematic config files? i found some pastebin links in our email archives, but they had all expired
yes, just a sec
[22:05:02] <PCW> http://filebin.ca/ffgtdo
[22:05:04] <PCW> http://filebin.ca/vnoeue
(Rick Gs config)
oh yeah, i think you sent me this one at the cnc workshop
it's got the crazy 500K steps/inch on X and super tight ferror (.0001)
Maybe that's the one that worked OK for you :-(
and the crazy short step timings
Y and Z look normal, but X looks kind of wacky
yes its out there (as is C. Morleys with super long dir setup and hold)
I can probably run those configs on my system (no hardware to move, of course, but it's stepper so it doesn't matter much)
what are the steps to produce the problem? the symptom is an ferror, right?
i think it's an ferror on a move of the x axis in the negative direction, but i'm not 100% sure of that...
after minimal changes to the ini and hal given earlier, I have not seen ferrors in 2-3 minutes of running
I edited the ini to set a 50us base period; I notice there are multiple settings in that file
emc2 2.4.0 on 10.04
no trouble yet using the odd 300000 BASE_PERIOD either
Well that makes it hard to debug. Wonder if its somehow specific motherboard/CPU related
or maybe I'm just not following the right steps
jepler: By definition you are following the right steps, but not the wrong ones.
when there's a base thread, it interrupts the servo thread (has higher priority). Even if no functions are in the thread, it does take some time to enter and return from the timer interrupt. That makes the time between read and write more variable, and the time between read and read more variable, than without the base thread
I wonder if the difference can be enough to make the position control of the stepper unstable
Is there any possibililty that an empty base thead doesn't do the housekeeping that a populated one would, and leaves something on the stack?
that's not the first hypothesis that leaps to mind.
I hate to rule anything out :-P
It is a hypothesis rooted in a position of ignorance, I admit.
the thing that runs a thread's functions in order is in src/hal/hal_lib.c, function thread_task
basically, it goes through the list of functions as a linked list
but the list is empty, so the first while (funct_entry != funct_root) test fails
that's the theory, anyway
to pursue your "an empty thread is trouble" theory, you could add a very simple function -- like charge-pump -- to base_thread and see if it changes anything
bbl, it's time for dinner and a show here
I haven't tried to reproduce the problem, but given that nobody else can I think it might be a frustrating passtime.
A coule of cuomer have had the problem and C. Morley, the pncconf/classic ladder? developer
spelling fail... A copule of customers have had the problem and C. Morley, the pncconf/classic ladder? developer
I am just happy to have a working config, I don't really want to break it.
time to go home... couple couple couple
My 2.4.1 installation has stopped working, oddly. Fortunately the 2.5~pre is OK still.
Strange, but maybe a upgrade mixed old/new issue?
I tried a recompile of 2.4.1 but it can't load RTAI. I lost interest in figuring it out, I wanted to make parts.
i'm going home too
see you guys later
That would sure stump me...
BTW the sserial info I sent is obsolete, we added some more registers (now 3 per channel) so the
status/control info is separated from the comm channel data. Currently all comm errors are fatal
(timeouts or CRC errors) except when starting (unused channels will try forever to establish communication)
No worries, I have got pretty much exactly nowhere yet. I bought a new miller and that is distracting me.
I saw the pictures, looked like a nice machine
Still hasn't turned more than a coolant pump.
I am probably going to experiment with a home-made VFD this weekend.
Ok that the high voltage motor?
dont blow up...
It occurs to me that for just making dumb 415V 50Hz 3-phase you don't have to spend £300 on an all-singing, all-dancing variable frequency, current limiting, soft-starting, PID-controlling VFD.
Well as long as you have a crude but fast over-current shutdown...
There was some delay when I found that the IRAMS modules are not really happy with 600V, the spec really says 450 and max-blocking DC is 600.
The way I see it, the worst you get is the motor shorted to the mains. And that is how it was designed to run...
Yep 600V modules are for 240V line, 1200V module for 480V
I have a 3-phase MOSFET driver and 6 20A 1000V Mosfets to play with. At least they all only cost pennies when the magic smoke escapes/
We have a few 1200V modules around but none with built in gate drivers
I am only expecting to see 600V on the DC bus, so 1000 sounds like ample headroom.
just noting industry practice...
I probably won't end up using it, but I am interested in the concept of using a voltage doubler and inverter.
I think most PC supplies work that way (120V doubled or 240V straight)
I guess 440V 3P (600V rail-rail) sounds a lot higher to folks in the US with your rather effete and non-lethal mains voltage
240V is scary enough
I have touched 240V several times. It really is very unpleasant, but so far non-fatal.
luckily with all of our testing of the 8I20 weve neither blown up the module or gotten shocked
though we are still using an isolated supply (but we need to ground motor V- sometimes to
scope DSP signals)
I searched the web for rules of scoping floating supplies, and there seemed to be two conflicting schools of thought.
There's so much PWM noise that the only way we get decent current waveforms for test is using a Hall sensor in the motor leads (as the 8I20 uses)
I guess a current transformer would address the issue nicely
Sure except for DC
We did find we need to add a (big) ferrite bead on the motor leads to prevent the fast DVDT from the PWM
from injecting so much ground return current from the winding capacitance to motor frame to everywhere...