Back
[21:08:30] <PCW> Hi sebastian
[21:10:36] <seb_kuzminsky> hi there :-)
[21:11:51] <PCW> When you checked the basethread issue with HostMot2s stepgen how did you create the base thread?
[21:13:13] <SWPadnos> are you asking how to create multiple threads, or what his setup was like? (I can answer only one of those questions :) )
[21:14:12] <seb_kuzminsky> i used a config that someone sent me that had the basethread
[21:14:17] <seb_kuzminsky> i think it was made with pncconf
[21:15:03] <PCW> Oh ok its the pncconf configs where the problem first showed up
[21:23:32] <PCW> 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
[21:24:22] <PCW> These are for forward and reverse motions with base thread enabled (showing the error)
[21:26:11] <seb_kuzminsky> is this with 2.4.2 or with an older version?
[21:26:32] <PCW> I think 2.4.1
[21:26:42] <seb_kuzminsky> i fixed some bugs at the cnc workshop that may be related to this
[21:27:02] <seb_kuzminsky> the fixes went into the 2.4.2 release
[21:29:40] <PCW> ISTR you were never able to duplicate the problem
[21:30:42] <seb_kuzminsky> 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
[21:31:49] <PCW> I just cant figure what the base thread has to do with anything (other than maybe adding more jitter to the servo thread)
[21:36:05] <seb_kuzminsky> PCW: i agree, especially since the pncconf base thread was empty...
[21:36:14] <seb_kuzminsky> i'm currently thinking it's a coincidence
[21:38:36] <PCW> 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
[21:38:37] <PCW> (both with pncconf generated HAL files)
[21:41:22] <SWPadnos> 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
[21:41:53] <SWPadnos> the base thread period becomes the timing "chunk", rather than whatever timer is used
[21:46:34] <PCW> Three base thread timings were tried (looking at Ricks .ini file)
[21:46:36] <PCW> 50 uSec, 150 uSec and 300 uSec, all caused trouble
[21:47:22] <PCW> ( the 50 uSec should have not changed the requested 1 mSec servo thread
[21:47:28] <SWPadnos> 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)
[21:47:33] <SWPadnos> yes, it might
[21:48:00] <SWPadnos> if the timing source can't do exactly 50 uS, then something close will be chosen, say 48.9
[21:48:34] <SWPadnos> the closest you can get to 1000 with 48.9 as your resolution is 978
[21:48:40] <SWPadnos> (without going over)
[21:49:00] <SWPadnos> that's a lot worse than ~998.9, which it might be if the servo thread were the only one
[21:49:20] <SWPadnos> (those numbers are bogus, and just used for illustrative purposes)
[21:50:01] <SWPadnos> 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
[21:50:26] <SWPadnos> the other one is what you identified, that latency/jitter may be different
[21:52:51] <PCW> So the question now is what number the HM2 stepgen uses for its calcs, the 1 mS or 998.9 uSec
[21:55:00] <PCW> 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)
[21:58:38] <seb_kuzminsky> hm2 uses the reported thread period in its calculations
[21:58:41] <SWPadnos> I believe that the "period" value passed to functions is the actual thread period (in RT anyway, there's an option in sim)
[21:58:54] <seb_kuzminsky> i think this time is the actual thread time used by hal/rtai
[21:59:06] <SWPadnos> thread period, not thread time
[21:59:19] <seb_kuzminsky> period, yes
[21:59:39] <SWPadnos> and it isn't compensated for other functions in the thread that may have varying execution times (not that it should matter much)
[21:59:46] <SWPadnos> or for latency
[22:02:41] <seb_kuzminsky> 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
[22:03:36] <PCW> yes, just a sec
[22:05:02] <PCW> http://filebin.ca/ffgtdo
[22:05:04] <PCW> http://filebin.ca/vnoeue
[22:06:59] <seb_kuzminsky> thx
[22:07:05] <PCW> (Rick Gs config)
[22:08:53] <seb_kuzminsky> oh yeah, i think you sent me this one at the cnc workshop
[22:09:28] <seb_kuzminsky> it's got the crazy 500K steps/inch on X and super tight ferror (.0001)
[22:09:36] <PCW> Maybe that's the one that worked OK for you :-(
[22:09:36] <seb_kuzminsky> and the crazy short step timings
[22:09:55] <seb_kuzminsky> Y and Z look normal, but X looks kind of wacky
[22:10:57] <PCW> yes its out there (as is C. Morleys with super long dir setup and hold)
[22:11:09] <PCW> (times)
[22:16:58] <jepler> 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)
[22:17:18] <jepler> what are the steps to produce the problem? the symptom is an ferror, right?
[22:19:52] <seb_kuzminsky> 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...
[22:35:21] <jepler> after minimal changes to the ini and hal given earlier, I have not seen ferrors in 2-3 minutes of running
[22:35:38] <jepler> I edited the ini to set a 50us base period; I notice there are multiple settings in that file
[22:36:17] <jepler> emc2 2.4.0 on 10.04
[22:40:19] <jepler> no trouble yet using the odd 300000 BASE_PERIOD either
[22:44:17] <PCW> Well that makes it hard to debug. Wonder if its somehow specific motherboard/CPU related
[22:48:40] <jepler> or maybe I'm just not following the right steps
[22:49:30] <andypugh> jepler: By definition you are following the right steps, but not the wrong ones.
[22:50:01] <jepler> 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
[22:50:32] <jepler> I wonder if the difference can be enough to make the position control of the stepper unstable
[22:52:37] <andypugh> 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?
[22:53:12] <jepler> that's not the first hypothesis that leaps to mind.
[22:53:20] <jepler> I hate to rule anything out :-P
[22:54:04] <andypugh> It is a hypothesis rooted in a position of ignorance, I admit.
[22:54:54] <jepler> the thing that runs a thread's functions in order is in src/hal/hal_lib.c, function thread_task
[22:55:15] <jepler> basically, it goes through the list of functions as a linked list
[22:55:49] <jepler> but the list is empty, so the first while (funct_entry != funct_root) test fails
[22:55:52] <jepler> that's the theory, anyway
[22:56:34] <jepler> 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
[22:56:59] <jepler> bbl, it's time for dinner and a show here
[23:04:08] <andypugh> I haven't tried to reproduce the problem, but given that nobody else can I think it might be a frustrating passtime.
[23:16:32] <PCW> A coule of cuomer have had the problem and C. Morley, the pncconf/classic ladder? developer
[23:17:10] <PCW> spelling fail... A copule of customers have had the problem and C. Morley, the pncconf/classic ladder? developer
[23:17:30] <andypugh> I am just happy to have a working config, I don't really want to break it.
[23:17:44] <PCW> time to go home... couple couple couple
[23:18:12] <andypugh> My 2.4.1 installation has stopped working, oddly. Fortunately the 2.5~pre is OK still.
[23:19:51] <PCW> Strange, but maybe a upgrade mixed old/new issue?
[23:23:30] <andypugh> 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.
[23:30:57] <seb_kuzminsky> i'm going home too
[23:30:59] <seb_kuzminsky> see you guys later
[23:31:51] <PCW> That would sure stump me...
[23:31:52] <PCW> BTW the sserial info I sent is obsolete, we added some more registers (now 3 per channel) so the
[23:31:54] <PCW> status/control info is separated from the comm channel data. Currently all comm errors are fatal
[23:31:55] <PCW> (timeouts or CRC errors) except when starting (unused channels will try forever to establish communication)
[23:33:07] <andypugh> No worries, I have got pretty much exactly nowhere yet. I bought a new miller and that is distracting me.
[23:33:55] <PCW> I saw the pictures, looked like a nice machine
[23:34:34] <andypugh> Still hasn't turned more than a coolant pump.
[23:35:02] <andypugh> I am probably going to experiment with a home-made VFD this weekend.
[23:35:18] <PCW> Ok that the high voltage motor?
[23:35:32] <PCW> (thats)
[23:35:50] <PCW> dont blow up...
[23:36:20] <andypugh> 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.
[23:37:04] <PCW> Well as long as you have a crude but fast over-current shutdown...
[23:37:11] <andypugh> 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.
[23:38:20] <andypugh> 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...
[23:38:46] <PCW> Yep 600V modules are for 240V line, 1200V module for 480V
[23:40:51] <andypugh> 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/
[23:42:31] <PCW> We have a few 1200V modules around but none with built in gate drivers
[23:43:08] <andypugh> I am only expecting to see 600V on the DC bus, so 1000 sounds like ample headroom.
[23:43:49] <PCW> just noting industry practice...
[23:43:57] <andypugh> I probably won't end up using it, but I am interested in the concept of using a voltage doubler and inverter.
[23:44:48] <PCW> I think most PC supplies work that way (120V doubled or 240V straight)
[23:46:41] <andypugh> 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
[23:47:15] <PCW> 240V is scary enough
[23:48:13] <andypugh> I have touched 240V several times. It really is very unpleasant, but so far non-fatal.
[23:49:32] <PCW> luckily with all of our testing of the 8I20 weve neither blown up the module or gotten shocked
[23:49:33] <PCW> though we are still using an isolated supply (but we need to ground motor V- sometimes to
[23:49:35] <PCW> scope DSP signals)
[23:50:21] <andypugh> I searched the web for rules of scoping floating supplies, and there seemed to be two conflicting schools of thought.
[23:53:35] <PCW> 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)
[23:54:30] <andypugh> I guess a current transformer would address the issue nicely
[23:55:03] <PCW> Sure except for DC
[23:58:12] <PCW> We did find we need to add a (big) ferrite bead on the motor leads to prevent the fast DVDT from the PWM
[23:58:14] <PCW> from injecting so much ground return current from the winding capacitance to motor frame to everywhere...
[23:58:22] <PCW> (needed)