Back
[06:58:13] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 9312b0b 06linuxcnc 10(19 files in 2 dirs) stepconf -refactor to use GTK Builder and Notebook * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9312b0b
[06:58:13] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 6ea4bbe 06linuxcnc 10src/emc/usr_intf/stepconf/base.glade 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -have stepconf reset the axis defaults on unit change * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6ea4bbe
[06:58:13] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder e59adb1 06linuxcnc 10src/emc/usr_intf/stepconf/finished.glade 10src/emc/usr_intf/stepconf/main_page.glade 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -make the navigation buttons direct the user * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e59adb1
[06:58:17] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 871a13b 06linuxcnc 10(6 files) stepconf -add a second parallel port signal selection page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=871a13b
[07:12:20] <linuxcnc-build> build #830 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/830 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[07:12:20] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:13:13] <linuxcnc-build> build #1627 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1627 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>,
[07:13:13] <linuxcnc-build> Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:14:26] <linuxcnc-build> build #1629 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1629 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>,
[07:14:26] <linuxcnc-build> Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:15:12] <linuxcnc-build> build #1629 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1629 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[07:15:12] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:15:19] <linuxcnc-build> build #1626 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1626 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[07:15:19] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:17:02] <linuxcnc-build> build #1630 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1630 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[07:17:02] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:17:16] <linuxcnc-build> build #1628 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1628 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[07:17:16] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:17:26] <linuxcnc-build> build #1625 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1625 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[07:17:26] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:17:36] <linuxcnc-build> build #1628 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1628 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert
[07:17:36] <linuxcnc-build> Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:17:53] <linuxcnc-build> build #1625 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1625 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[07:17:53] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:24:03] <linuxcnc-build> build #1424 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1424 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant
[07:24:03] <linuxcnc-build> <tissf@free.fr>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:24:03] <linuxcnc-build> build #1630 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1630 blamelist: dummy, John Thornton <jthornton@gnipsel.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Chris S Morley <chrisinnanaimo@hotmail.com>, Francis Tisserant <tissf@free.fr>, Norbert Schechner
[07:24:03] <linuxcnc-build> <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>
[07:47:04] <skunkworks> I did a ./mesaflash --device 7i80 --ip=10.10.10.10 I then rebooted the board with jumpers w1,w1 down,up. it still pings at the 192.168.1.121 address
[08:02:15] <skunkworks> ok - I did a ./mesaflash --device 7i80 --ip 192.168.1.121 ip=10.10.10.10 an now it doesn't ping when I have the jumpers set down,up but when I change the nic's address to 10.10.10.1 I can't find the card
[08:07:57] <skunkworks> heh - rfm.. set ip=10.10.10.10
[08:16:37] <skunkworks> (didn't help)
[08:32:51] <skunkworks> dxfin
[08:32:58] <skunkworks> heh
[09:45:01] <pcw_home> you need a set command to set the ip address
[09:46:50] <pcw_home> --set
[09:48:35] <pcw_home> ./mesaflash --device 7I80 --set ip=x.y.z.t
[09:49:53] <pcw_home> (and of course you will need to change your network setup to access x.y.z.t)
[10:00:25] <skunkworks> yep - got it working. - just didn't help the watchdog issue. (trying everyting I can think of)
[10:34:03] <pcw_home> you can get it to work and I cant get it to fail...
[10:34:04] <pcw_home> (Ive had a 7I80DB running under linuxcnc on a D525 for a week now with nary a glitch)
[10:34:34] <cradek> skunkworks: take your parts, put them in a box, and send them to pcw
[10:35:02] <skunkworks> That is a good idea!
[10:35:23] <cradek> then he can use science! to troubleshoot!
[10:35:34] <cradek> using science! is good!
[10:35:45] <pcw_home> Or I can send you the 7I80DB thats been running all week
[10:35:50] <skunkworks> wait - are you saying I am just flailing aimlessly?
[10:35:57] <cradek> you have to say "science" in that radio-announcer voice
[10:36:09] <cradek> no, I meant he has working parts to swap around
[10:36:26] <cradek> and probably logic-analyzer thingies and other wizardry
[10:36:46] <skunkworks> (I am flailing around aimlessly)
[10:37:05] <skunkworks> I have a good voice for science
[10:37:08] <skunkworks> ;)
[10:40:23] <pcw_home> I suspect its some subtle memory corruption issue in the driver (how can 0xFFFFFF00 .and. 0x00000001) = true
[10:41:51] <skunkworks> I could send you a hd and the card.. (I have tried it in enough ssytems that it has to be either the install or card...
[10:41:58] <cradek> I always suspect byte-order problems when I see all those void* and words broken up into char arrays and /4 and *4 counts in the driver. it's all baffling to me, which might be the code or it might be me
[10:46:25] <pcw_home> Yes it could well be an alignment issue, but why only on Skunkworks system remains a mystery
[10:46:37] <cradek> yeah
[10:47:08] <cradek> skunkworks: if you're going to do it, do it only once - I'd send everything just exactly as it is
[10:48:26] <skunkworks> sure - the atom board doesn't take up much space
[10:48:54] <cradek> [I used to do hardware and software support...]
[10:50:18] <pcw_home> however its done, a binary search through components seems in order
[10:54:07] <pcw_home> skunkworks: did you say you've seen that bug in the latency test when the latency decreases?
[10:54:15] <skunkworks> yes
[10:54:28] <pcw_home> only on preemt_rt?
[10:54:37] <pcw_home> I ve never seen it on RTAI
[10:55:11] <skunkworks> popped up to like 80us then back down to 60us. I have only seen it in the rtpreempt
[11:33:16] <skunkworks> pcw_home, you say you tried the d945gclf2?
[11:34:10] <skunkworks> one of these?
http://www.mini-itx.com/reviews/atoms/?page=6
[11:39:34] <pcw_home> Yes, that one
[11:41:53] <skunkworks> ok. would you have a problem if I packed up the HD, 7i80, and motherboard and sent it to you?
[12:19:34] <pcw_home> No problem if you dont mind. since I have a copy of 7I80/NM/HD is can swap one at a time
[12:28:04] <skunkworks> andypugh, !
[12:28:53] <andypugh> We are too cautious about Gantrykins. By stressing the flaws, we seem to be persuading people that Mach3 (which does exactlty the same slightly wrong thing when homing) or wierd HAL-munging is better.
[12:31:23] <mozmck> what is slightly wrong about the homing?
[12:32:12] <andypugh> One side of the gantry can be doing a rapid-to-home while the other is still doing a slow latch move.
[12:32:28] <andypugh> They can even possibly be moving in different directions.
[12:33:30] <mozmck> hmm, I've never seen that with Mach - ever.
[12:33:31] <andypugh> It gets hard to decide what to do with index-homng, especially if the encoders are not aligned.
[12:34:31] <andypugh> I have never seen Mach do anything at all, so I am basing my opinion on a description from the forum. Maybe Mach does home gantries better than LinuxCNC does.
[12:35:02] <mozmck> and we use and sell Mach with dual-drive gantry setup almost exclusively, so we would have heard of that.
[12:35:39] <andypugh> But the Mach3 solution to gantry homing seems to be to wire the home-all button to home both axes at the same time, which certainly sounds like it will have the same issue with the two sides potentially being at different points in the sequence.
[12:35:56] <mozmck> But I don't know about index-homing as nothing we use has that.
[12:36:19] <andypugh> Well, if Mach does it correctly, then _how_ does it do it?
[12:37:14] <mozmck> When you have a "slaved" axis as mach calls it, the 2 axes both move to the home switches at the same speed, and as each switch closes that side stops.
[12:38:12] <mozmck> when they have both closed the gantry backs off until the switches open again.
[12:38:23] <andypugh> So, it stops and waits for it's "friend" before starting the latch move?
[12:38:55] <mozmck> what is a latch move? where it backs off the switch?
[12:39:40] <andypugh> Yes, or when it moves slowly back on to the switch, depending on how homing is configured.
[12:39:43] <mozmck> but yes, if the gantry is out of square then the side that hits the switch first stops until the other side hits it's switch.
[12:39:51] <mozmck> Ok, yes.
[12:40:33] <pcw_home> with index you can align before you get home (assuming you are never racked more than 1/2 a turn)
[12:41:30] <andypugh> We did talk about tryiing a spaghetti gantry to test things out :-)
[12:41:50] <pcw_home> and with absolute you can unrack optimally
[12:41:56] <andypugh> pcw_home: How do you configure for non-aligned indexes?
[12:41:57] <mozmck> I guess so, but how would you make sure you are not out more than that? It doesn't happen much but it can happen if something goes wrong.
[12:42:24] <pcw_home> you need the offset as a setup constant
[12:42:35] <mozmck> Well, my router table is gantry but only single drive. I need to convert it because at 4 ft wide it really needs 2 drives.
[12:42:51] <andypugh> I think it is safest to move to the switches first, that way at least the racking won't get worse before it gets better.
[12:43:27] <pcw_home> if something goes that wrong its arguable that you need to fix before homing anyway
[12:43:48] <mozmck> One thing we do is turn the power to the motors off and if the gantry is racked much it is stiff enough to pull back close to right before powering back on and homing.
[12:44:42] <andypugh> That should work even better with servos.
[12:47:16] <archivist> with some strain gauges one can measure the twist
[12:48:23] <mozmck> anyhow, I don't know if Mach's method is great, but the axes always move at the same speed and direction no matter what happens (assuming it is set up correctly!)
[12:49:03] <mozmck> Axes may not be the correct terminology for LinuxCNC - joints maybe?
[12:51:18] <pcw_home> so crab toward home till you hit both switches, decell and stop together and then back off both at once (stopping individually) ?
[12:54:02] <mozmck> Unless I have something wrong, that's how Mach does it, although I think it stops at each switch as it hits it.
[12:54:35] <mozmck> The homing movement is slow so it can stop quickly.
[12:54:38] <mozmck> bbl
[13:16:36] <mozmck> From the forum: "I hope it is going to be on the a gender for the future" :)
[13:17:24] <mozmck> it's on my a-gender to look at the gantry stuff for sure.
[13:24:24] <skunkworks> pcw_home,
http://imagebin.org/285024
[13:24:49] <skunkworks> so - it will run without the watchdog enabled?
[13:25:18] <skunkworks> I suppose the outputs are not enabled..
[13:25:29] <skunkworks> but internally - everthing is running?
[13:27:01] <pcw_home> must be
[13:27:50] <skunkworks> if I set the hasbit to false. it instantly goes to true and I get the encoder count error
[13:28:16] <skunkworks> >| |< close...
[13:29:13] <skunkworks> well - I think I have the system setup to run. I will throw it in a box and send it out.
[13:29:28] <pcw_home> yeah but whats the difference? watchdog all all my test machines works just as expected
[13:29:45] <skunkworks> sure.. No clue..
[13:30:30] <skunkworks> I used your config - it ran right off the bat.. (last install - I could not get it to run without a following error.)
[13:30:47] <skunkworks> (but I had changed so much stuff - who knows)
[13:30:56] <cradek> I will send my spaghetti servos/switches/encoders+index gantry to anyone who's serious about getting gantry homing working in a sane way and committed to our git
[13:31:29] <skunkworks> This is a fresh updated 12.04, rtpreempt, linuxcnc installed.
[13:32:15] <mozmck> cradek: I may get serious before too long here, but we have some gantry machines I can test on.
[13:32:35] <cradek> do they have dual switches and encoders with index?
[13:32:41] <mozmck> I plan to convert my router to dual drive and I will have motivation then for sure.
[13:32:57] <mozmck> dual switches? You mean one for each side? yes.
[13:33:05] <cradek> (it seems to me that index reset is the hardest part)
[13:33:09] <mozmck> encoders, but no index.
[13:34:07] <mozmck> I may need some encoders with index, or I might have that and just need to use the index. I have small DC servos.
[13:34:27] <cradek> I think index is an important part of doing the project in a complete way (handling all the homing models and states)
[13:35:01] <mozmck> I'm sure it is.
[13:35:02] <cradek> ok, also let me know if digging in my encoder junkbox would help you
[13:35:08] <mozmck> ok, thanks.
[13:35:53] <cradek> I'm a little dejected because I've started that project at least twice and never finished it...
[13:38:45] <cradek> my silly attempt that was never quite right:
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/synchronized-homing
[13:39:13] <cradek> I didn't have the heart to brute-force it by adding a new state after each existing state, but I think that would probably actually work
[13:39:22] <mozmck> heh, I know the feeling!
[13:40:52] <mozmck> Does it already handle syncronizing the rest of the motion?
[13:41:00] <cradek> this attempted to use the existing homing sequence to determine which joints were slaved
[13:41:27] <cradek> I don't understand what you are asking there. what rest of motion?
[13:42:01] <mozmck> If two joints are slaved they should move together all the time. I presume homing is the only thing that is not quite right?
[13:43:21] <cradek> well assuming you can use kins for making joints move together correctly after homing, homing is the only remaining thing
[13:44:04] <cradek> you could also perhaps slave joints at the hal level, and I think it could be done entirely with a hal component, but that component would need to be intimate with the homing state machine, so the whole approach feels wrong
[13:44:40] <cradek> if I were working on this today (for the 4th time) I'd certainly start on top of joints_axes4
[13:44:56] <mozmck> ok, I'll have to dig into it later.
[13:44:58] <cradek> [tell me if I have not yet answered your question...?]
[13:45:07] <mozmck> I think you have :)
[13:45:52] <mozmck> is joints_axes4 close to being merged into master?
[13:45:54] <cradek> I'm surprised my branch is not on top of ja3 but I think it's not...
[13:46:24] <cradek> my opinion is that if ja4 doesn't go into 2.6 [and I think it won't] that we must merge it right after making v2.6_branch
[13:46:34] <mozmck> ok
[13:46:51] <cradek> and I would be a bit surprised if anyone strongly disagrees with that
[13:47:11] <cradek> so the answer is it's sorta close, I think
[13:47:23] <mozmck> ok
[13:47:37] <cradek> closer than ever! (just like you're older than you've ever been)
[13:47:49] <mozmck> :)
[13:47:58] <cradek> that's a great song
[13:51:09] <pcw_home> I wonder if there any way for motion to provide forward differences to HAL
[13:51:11] <pcw_home> (rather then the current backward differences)
[13:51:34] <cradek> pcw_home: the current-vel outputs are not it?
[13:51:55] <pcw_home> nope
[13:52:21] <cradek> explain?
[13:52:56] <pcw_home> http://imagebin.org/283659
[13:54:29] <pcw_home> for this to be right, velocity must be calculated for next next waypoint, not the last one
[13:54:38] <pcw_home> the next
[13:55:18] <cradek> does that mean the same as latching and delaying the target position by one period?
[13:55:37] <pcw_home> Yes
[13:55:53] <pcw_home> (and all that entails)
[13:55:54] <cradek> that sounds easy; you can do it in hal
[13:56:02] <cradek> but sorry about homing :-/
[13:56:18] <pcw_home> except ferror
[13:57:35] <cradek> the position command (I think) means this is where I want you to be at the end of this period (right?)
[13:58:09] <cradek> but what is the vel command? at the end of this period you should be moving this fast (through the command position)?
[13:59:18] <pcw_home> motion hardware (to be correct) needs to know the current desired position and how to get to the next waypoint
[14:01:55] <pcw_home> (how to get to the next waypoint for a PID velocity mode control is FF1)
[14:01:56] <pcw_home> FF2 is broken as well in the same way
[14:02:45] <cradek> could you doodle what you think is wrong on that plot (draw what the right thing would be)?
[14:03:09] <cradek> the scales on pos and vel are different by 2/5 but it's still fairly clear
[14:04:15] <cradek> I assume the red is there but flatlined?
[14:04:59] <pcw_home> yeah but its pretty basic, to have "perfect" velocity mode you need the velocity to get to the next position
[14:05:01] <pcw_home> not how you got to the current position (you need to extrpolate)
[14:05:09] <pcw_home> red is the same as white
[14:05:10] <cradek> is the error-previous-target fix not right?
[14:05:37] <pcw_home> the fix is required or its hopeless
[14:07:21] <cradek> I don't really understand how current/next command/feedback position/vel all fit together
[14:07:49] <cradek> when you quantize it in time, it gets all crazy and I don't understand what's "right"
[14:08:04] <pcw_home> imagine a perfect velocity mode drive (the stepgen is very close to perfect)
[14:08:15] <cradek> what does that mean?
[14:08:28] <cradek> I don't know how a perfect velocity mode drive behaves
[14:08:43] <pcw_home> i have no feedback just FF1
[14:09:14] <cradek> ok once a second I give it a new velocity command. what does it do?
[14:09:42] <cradek> jumps instantly to that velocity and moves at that velocity for the coming second?
[14:09:52] <pcw_home> Yes
[14:09:59] <cradek> ok then, imagined
[14:11:53] <pcw_home> so starting from 0 velocity if my velocity command for the first 1 second segment is one second late
[14:11:55] <pcw_home> I will miss my first waypoint by VT
[14:13:22] <pcw_home> in other words I need the velocity required to get to the next waypoint
[14:13:23] <pcw_home> not the velocity that got us to the current one
[14:13:41] <pcw_home> (which is what we have now)
[14:13:42] <cradek> if the first command position is 1, the first command vel should also be 1, right? because it'll go 1in/sec for 1sec and get to 1in
[14:14:35] <pcw_home> yes but currently the first command velocity will be 0
[14:14:37] <cradek> but I think that's what I see in the green and cyan lines in your plot
[14:14:45] <cradek> are you sure?
[14:15:01] <cradek> the green and cyan lines jump at the same time to (I think) the same value
[14:15:36] <pcw_home> thats the problem
[14:15:41] <cradek> I'm lost
[14:15:49] <cradek> you just said that was correct with my example of all 1s
[14:17:37] <cradek> in your plot the first period's vel is 200u/period and and first period's position is 200u
[14:17:48] <pcw_home> the cyan would have to lead the green by one sample to be correct
[14:17:49] <pcw_home> (current pos is 0 but velocity must be 1 to instruct the hardware how to get to the next waypoint)
[14:18:06] <pcw_home> (with your numbers)
[14:18:34] <cradek> but that doesn't agree with how you said a perfect velocity mode amp works
[14:19:11] <pcw_home> ?
[14:19:17] <cradek> rereading
[14:22:49] <pcw_home> looked at another way, starting at 0 velocity the only way
[14:22:51] <pcw_home> I can get to the first waypoint correctly the first sample after
[14:22:52] <pcw_home> motion starts is by having the velocity lead the position
[14:23:47] <mozmck> makes sense, at 0 vel you go nowhere
[14:23:53] <cradek> I'm still missing something. do our two commands, set at the same time, mean "move at this velocity during the coming period" and "at the end of that period I expect you to be at position"
[14:24:58] <pcw_home> I would think so
[14:25:34] <cradek> then the plot looks right to me, and is just like my example with 1s, and I don't yet follow your objection
[14:26:16] <cradek> you are saying "move at velocity 1 during the coming period" but "at the end of that period I expect you to STILL BE at 0"
[14:26:25] <cradek> which is clearly wrong
[14:26:36] <cradek> what am I missing?
[14:27:29] <cradek> you are saying [by proposing we change vel a period earlier]
[14:28:49] <cradek> brb, I will read back
[14:31:44] <pcw_home> if you look at the plot again
[14:31:46] <pcw_home> at one sample, position and velocity are 0
[14:31:47] <pcw_home> at the next the position has changed to 200u
[14:31:49] <pcw_home> but the velocity command which applies for the next period told it to stay still
[14:31:50] <pcw_home> (hence the following error)
[14:36:28] <cradek> if this from earlier is true (do our two commands, set at the same time, mean "move at this velocity during the coming period" and "at the end of that period I expect you to be at position") then they should change from zero simultaneously in your plot, and they do
[14:36:47] <mozmck> Looks to me like the position changes to 200u at the same time the vel changes to about 100m.
[14:37:09] <cradek> I think they both change to 200u
[14:37:27] <cradek> the scale is 2 vs 5
[14:37:59] <mozmck> So position should not be at 200u, but that's where it should be moving next period at the new vel.
[14:38:30] <mozmck> you're right.
[14:40:36] <cradek> yes 200u of position is expected after this 1ms period if you move at 200m/inch for 1 ms
[14:41:49] <cradek> my understanding of how a perfect velocity mode amp would work (above) and what our two commands mean (not so far above) seem to me to match
[14:42:20] <cradek> hm, I notice after the first period the ferror is zero
[14:42:30] <pcw_home> ferror is delayed
[14:42:53] <mozmck> Is the error because it takes actual time to accelerate to vel-cmd?
[14:43:04] <cradek> but error-previous-target means "Use previous invocation's target vs. current position" which also matches our model
[14:43:12] <pcw_home> This is a stepgen (no inertia)
[14:43:22] <mozmck> oh.
[14:44:45] <cradek> are you sure you don't just have your thread misordered or something? or is one of my understandings above wrong? I tried to spell them out.
[14:45:13] <pcw_home> the error that error-previous-target fixed for the PID loop is basically the same error
[14:45:15] <pcw_home> (backward differences) in motion. to get to the next waypoint, velocity must lead position
[14:46:15] <cradek> you keep saying that, but I think it is not true if my stated assumptions about what the commands mean are correct.
[14:48:14] <cradek> I'm not being dense on purpose [it comes naturally] but please tell me which assumption is wrong
[14:48:39] <pcw_home> if the hardware is handed 0 vel and 0 position and at the next sample period position is 200u, this is simply wrong
[14:49:07] <cradek> but we agreed that's not what the commanded position means
[14:49:31] <cradek> we agreed that the commanded position means: after the coming cycle, I expect you to be here
[14:49:44] <pcw_home> then commanded position is wrong
[14:49:45] <cradek> after you move at [vel] for a period I expect you to be at [pos]
[14:50:18] <pcw_home> (as illustrated by the PID hack)
[14:50:19] <cradek> now on the next cycle, feedback pos is read and compared to that remembered value, to see how we did
[14:50:24] <cradek> motion and pid both do it (now)
[14:51:25] <cradek> I think it is a consistent model and it matches your ideal velocity mode amp
[14:52:38] <pcw_home> well it results in unfixable errors so is just wrong so far as I am concerned
[14:53:19] <cradek> I think you must disagree with:? (do our two commands, set at the same time, mean "move at this velocity during the coming period" and "at the end of that period I expect you to be at position")
[14:53:55] <pcw_home> thats correct
[14:54:15] <cradek> um, I'm correct that you disagree?
[14:54:26] <pcw_home> position being _current_ desired position
[14:54:52] <pcw_home> not next not last but current
[14:55:07] <cradek> ok that is not what motion or pid (now) do. is that what stepgen does?
[14:55:20] <mozmck> If there is a velocity command but the position command is not until the next period then won't it possibly overshoot?
[14:55:48] <pcw_home> no it will get to the position at the next sample
[14:55:53] <cradek> perhaps stepgen is mistaken about the consistent model we finally have in motion and pid
[14:56:19] <pcw_home> this is with motion an PID
[14:57:21] <pcw_home> the stepgen illustrates the error well because its a "perfect" velocity mode servo
[14:58:26] <mozmck> Is the error an error in position?
[14:59:04] <pcw_home> Yes
[14:59:37] <cradek> does the stepgen calculate ferror internally and use it for something?
[15:00:31] <mozmck> So if the position is not what it should be then do you adjust velocity? If so I can see your point I think.
[15:00:31] <pcw_home> not in velocity mode
[15:01:57] <cradek> I think it is wrong to think of the commanded position to mean "I expect you are already here even before this period runs"
[15:02:08] <cradek> I think this is our model mismatch
[15:02:11] <pcw_home> This is running the stepgens in velocity mode in a PID loop (FF1 = 1.00 FF2= period, P= ~150)
[15:03:02] <pcw_home> but you can see that that model already requires some ugly patching around
[15:03:05] <cradek> neither motion nor pid think the commanded position means that (now)
[15:03:37] <cradek> well no, the "ugly patch" in pid was a simple bugfix IMO, and we made it optional so we didn't "break" existing (mis)tunings
[15:03:50] <cradek> it made it match what motion always meant
[15:05:30] <cradek> FF1=1 P=150 would not be a perfect tuning for our perfect amp, would it?? FF1=1 P=0 would be.
[15:06:00] <cradek> hm or would it matter
[15:06:12] <cradek> [maybe pid is still wrong]
[15:06:42] <pcw_home> yes P=0 if its was perfect
[15:06:53] <cradek> does that fix your plot?
[15:07:20] <pcw_home> its unfixable
[15:07:20] <cradek> er, make it better? (jitter will still make it drift)
[15:08:22] <pcw_home> P is low enough that is just slowly corrects for errors
[15:10:46] <pcw_home> Probably the existing HM2 stepgen driver should be tossed and replaced with a PID loop
[15:10:48] <pcw_home> since the existing one has trouble with jitter and th ePID loop scheme works much better
[15:11:46] <pcw_home> (and can use fixed tuning)
[15:12:20] <pcw_home> and avoids the need to set stepgen maxaccel or stepgen maxvel
[15:17:05] <cradek> if a fixed tuning works fine, that sounds great
[15:19:07] <pcw_home> yeah FF1 at 1 is obvious but FF2 at servo thread period was not
[15:22:50] <pcw_home> best thing is that the PID controlled stepgen works OK with 100s of usec of jitter
[15:23:36] <pcw_home> (set the PID max_error and jitter caused error peaks are just clipped)
[15:24:38] <pcw_home> (so they dont cause wild bogus corrections as they do with the stepgen driver)
[15:25:26] <cradek> a win! time to change the hm2 sample configs and pncconf?
[15:25:37] <cradek> (or is it stepconf?)
[15:26:35] <pcw_home> its doable now with stepgen code thats more like servo code, so just different hal boilerplate
[15:27:36] <pcw_home> but at some point the hm2 driver could be updated to be compatible but use PID inside
[15:28:01] <cradek> I think this is how the pico stepper configs work - I wonder why we(?) changed systems?
[15:28:26] <pcw_home> I think Seb started with the software stepgen as a model
[15:28:53] <cradek> I think the wisdom with the pico configs was that you had to tune their pids. this might have just been mistaken.
[15:29:19] <cradek> I don't remember if there were FF in emc1 - that would have been a big difference
[15:29:33] <pcw_home> AFAICT its basically fixed
[15:29:41] <cradek> that's great
[15:30:43] <pcw_home> in a way the difference is that the PID scheme can be set to "trust" the short term accuracy of the stepgen more
[15:31:39] <cradek> like just don't freak out, it'll be ok on average?
[15:31:46] <pcw_home> (rely mainly on FF1 and low pass filter the errors)
[15:31:50] <cradek> yeah
[15:32:23] <cradek> it does sound pretty easy to build that in if there's one optimal tuning
[15:32:38] <cradek> that would fix everyone's existing setups
[15:33:08] <pcw_home> yeah the current stepgen is like pig on stilts
[15:35:34] <pcw_home> as long as everything is cool it hobbles along
[15:35:36] <pcw_home> (I remember the first problems showed up when Linuxcnc moved from 8.04 to 10.04)
[15:35:37] <pcw_home> probably somewhat worse jitter
[15:36:59] <pcw_home> setting a reasonable stepgen_maxaccel works around the problem but not that well
[15:38:41] <pcw_home> I guess I should do some work today
[15:38:46] <pcw_home> bbl
[16:20:37] <seb_kuzminsky> hey zultron_ , i just tried to build a deb from ubc3 on a non-realtime machine, and it failed:
[16:20:40] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/ubc3-deb-bug
[16:21:23] <seb_kuzminsky> it looks like it's using the realtime (non-sim) .files file, looking for files that don't get installed when building without realtime support
[16:22:09] <seb_kuzminsky> i'm not sure how you guy have things set upfor building debs with various levels of realtime support in that branch, could you clue me in? i'll help with the deb part if you tell me what the right behavior should be
[21:00:12] <skunkworks> phillc54: are you the one testing the new trajectory planner from robert?
[21:04:51] <phillc54> yes, I intend to try it on my sherline mill
[21:05:49] <skunkworks> cool - I have not actually run real hardware with it yet. Just lots of constraint testing
[21:09:02] <phillc54> I am trying to integrate the max acc & vel counters into my machine at the moment
[21:09:53] <skunkworks> phillc54: is there a reason why you don't want to use master?
[21:11:37] <phillc54> only because I haven't used it before...
[21:12:12] <skunkworks> heh. it isn't so bad. :)
[21:12:39] <andypugh> I use it all the time, it has all the cool features (and generally only the really interesting bugs)
[21:12:55] <phillc54> I guess i am going to find out
[21:13:31] <skunkworks> heh. it isn't so bad. :)
[21:13:57] <andypugh> it's no real trouble to get it from the buildbot, and you can easily swap back
[21:14:10] <skunkworks> andypugh: I gave up and sent peter my system to see if he can figure out why I cannot get the 7i80 to work correctly
[21:14:43] <skunkworks> phillc54: as of this afternoon - roberts branch built successfully..
[21:14:54] <skunkworks> (did some light testing with it)
[21:15:11] <andypugh> skunkworks: Hopefully it isn't your local magnetic field then.
[21:16:57] <skunkworks> heh - maybe my time zone...
[21:17:53] <phillc54> i built it ok yesterday
[21:18:02] <skunkworks> I have tried it on enough systems to conclude it is either the 7i80 or they way I am installing 12.04.
[21:18:15] <skunkworks> and most likely something I am doing wrong with the install
[21:18:41] <andypugh> it seemed to work for me.
[21:19:51] <skunkworks> yes - you , peter and micges... rub it in
[21:19:51] <eric_unterhausen> skunkworks: 32bit or 64bit 12.04?
[21:19:58] <skunkworks> tried both
[21:20:06] <skunkworks> but 32 was what peter was using
[21:22:10] <skunkworks> the latency was decent for what it was (rt-preempt ) around 60-70us...
[21:22:23] <skunkworks> I just could not keep the watch dog from biting
[21:22:49] <pcw_home> and... d525/7i80/linuxcnc still running (thats ~24/7)
[21:23:03] <phillc54> now its built, if i want to update do i git pull, cd src, make clean then make or will make just build the updates
[21:24:09] <skunkworks> I always do a make clean then make - but I am a bit anal...
[21:24:29] <skunkworks> pcw_home: again - rub it in...'
[21:27:10] <phillc54> my first attempt at git and make...
[21:27:29] <skunkworks> it gets easier - after about a year of using it... ;)
[21:28:32] <pcw_home> I am really curious about whats going on
[21:28:34] <pcw_home> another possibility is sensitivity to the exact bitfile/config string
[21:28:59] <phillc54> i hope so, i'll get back to my machine now
[21:29:25] <skunkworks> phillc54: let us know how it runs!
[21:29:41] <skunkworks> you will probably be the second one running it on real hardware
[21:30:25] <phillc54> will do, bye
[21:30:37] <Tom_itx> skunkworks, referring to 2.6 ?
[21:31:14] <Tom_itx> i considered putting it on a ssd to try but so far haven't
[21:31:25] <skunkworks> Tom_itx: robert ellenbergs new trajectory planner
[21:31:30] <Tom_itx> ahh
[21:31:41] <Tom_itx> look better than the current one?
[21:33:47] <Tom_itx> is it in master now?
[21:34:49] <skunkworks> no - not yet. probably after they release the next version
[21:35:07] <skunkworks> Tom_itx: so far - it does lookahead (more than 1 segment)
[21:35:53] <skunkworks> so far - it looks ahead if the segments are line-line, tangent line-arc or tangent arc-arc
[21:36:40] <skunkworks> Tom_itx:
http://www.youtube.com/watch?v=oUajH5BCOUQ&feature=c4-overview&list=UUHk52YjGT8HryRYmJKSl-lg
[21:36:52] <skunkworks> he has come a long way in just a couple months
[21:40:57] <Tom_itx> yes
[21:41:34] <Tom_itx> was that line segments or arcs?
[21:41:37] <Tom_itx> or both
[21:43:13] <Tom_itx> no sound here so i dunno if there was any
[21:43:32] <skunkworks> I think that one was arc segments..
[21:43:42] <skunkworks> but it runs almost identical with line segments
[21:44:27] <Tom_itx> same programmed feeds and speeds?
[21:44:48] <Tom_itx> i would suppose so
[21:45:40] <skunkworks> yes - 30in/sec/sec and 500ipm max
[21:46:28] <Tom_itx> sure looks alot better
[21:47:09] <Tom_itx> i suppose it would perform the same on multi axis like a surface
[21:47:54] <Tom_itx> what about accuracy?
[21:48:08] <Tom_itx> wasn't there complaints about that on prior versions?
[21:50:49] <skunkworks> well - you can make it follow the path as close or lose as you want..
[21:53:24] <pcw_home> So if it the path has sharp corners it will always slow way down at the corner?
[21:54:08] <skunkworks> strait g64 says go as fast as you can but still touch every segment, then you can say Px.xxx Q0, which is stay within x.xxx of the original path. or Px.xxx Qy.yyy where it combines segments within y.yyy and then stays within x.xxxx
[21:54:50] <pcw_home> Those still work on the new TP?
[21:54:54] <skunkworks> pcw_home: it will go as fast as it can while still touching each segment atleast once. So - the sharp corner will be rounded at high speeds unless the tollerance is specified
[21:55:00] <skunkworks> pcw_home: yes
[21:55:50] <Tom_itx> is it hard to build that variant?
[21:56:02] <Tom_itx> considering i've never built any
[21:56:12] <pcw_home> Sounds great, though a bit scary to try on real hardware yet
[21:56:27] <Tom_itx> cut wax
[21:56:28] <andypugh> I am not clear where the "circular arc" part comes in, but I think there is also a lot more lookahead. I think he decided he could only do lookahead with circular blends, but I wasn't clear why.
[21:56:39] <skunkworks> I could give you directions... (but not tonight.) it isn't hard - pull the current master - then switch to roberts.
[21:56:48] <Tom_itx> i wouldn't wanna try tonight anyway
[21:57:20] <andypugh> Talking of Tempus Fugit.. Goodnight all
[21:57:23] <skunkworks> andypugh: I think because the math is easier - he can easially calculate the position along the path. Harder with parabolic blends
[21:57:28] <pcw_home> 'nite
[21:57:35] <Tom_itx> later andy
[21:58:19] <Tom_itx> you'd really need a cmm to test the accuracy
[21:58:31] <Tom_itx> and know the condition of your mill
[21:59:00] <Tom_itx> i know the mill is a bit sloppy and have no cmm
[22:00:11] <pcw_home> but the actual path deviation from gcode can be measured from by running sim
[22:01:17] <pcw_home> at least at the samples
[22:06:04] <pcw_home> I wonder if on a real machine you may actually get worse accuracy
[22:06:06] <pcw_home> with the new TP because of the higher acceleration
[22:06:07] <pcw_home> (though this is traded off for higher speed)
[22:07:51] <eric_unterhausen> if the speed is more even, then that should be good for part quality
[22:08:08] <eric_unterhausen> trading off for a little sloppiness in actual location of the tool
[22:09:10] <skunkworks> pcw_home: this expains it pretty well
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?TrajectoryControl
[22:09:45] <skunkworks> although they added Q to allow you to adjust path following separatly from the naive cam (adding segments together)
[22:09:55] <pcw_home> Yeah it would be nice to make cut identical shapes with both and compare
[22:09:56] <pcw_home> (also when set for same completion time)
[22:11:33] <pcw_home> skunkworks: yes Ive seen that I just did not realize that the new TP has the same features
[22:16:34] <skunkworks> yes
[22:17:02] <Tom_itx> like i say, someone with a good setup and cmm should try it
[22:17:58] <skunkworks> he did change Q - if Q isn't specified in the current tp it make q the same as p. (so you could be twice as far away from the program path in spots) he defaults Q to 0 unless specified.
[22:18:35] <cradek> I'd like to see the NCD gone
[22:19:02] <skunkworks> He seems to have thought about it quite well. He didn't just tear out and start new.. He used what cradek did and used that for a fall back for unhandled blends
[22:22:29] <pcw_home> Yeah I guess NCD is just added complexity if you have look-ahead
[22:22:54] <eric_unterhausen> does linuxcnc have a boa?
[22:23:08] <cradek> we don't have any snake that I know of
[22:23:21] <eric_unterhausen> BOA
[22:23:30] <eric_unterhausen> book of acronyms
[22:23:39] <cradek> haha
[22:27:07] <skunkworks> naive cam detector
[22:27:32] <skunkworks> which doesn't really explain it to me.. :)
[22:27:51] <Tom_itx> how much of the original govt project is still in the code?
[22:27:53] <Tom_itx> any?
[22:28:13] <eric_unterhausen> the TP had government cheese last time I looked
[22:33:28] <skunkworks> cradek: took your advice and sent it to peter. (almost forgot to put the 7i80 in the package)
[22:50:34] <Tom_itx> to get master i add the deb to the software sources?
[22:51:54] <atom1> i probably want lucid 32bit right?
[22:52:37] <atom1> do i want the deb or deb-src line?
[23:14:42] <zultron_> Hi seb_kuzminsky, happy New Year! My holidays are officially over, whew.
[23:15:31] <zultron_> We haven't ever built debs, so the packaging is probably untouched since pre-RTOS.
[23:17:35] <zultron> I can tell you how I build the RPM packages. The tricky bit is pkg deps, and maybe optional packages.
[23:18:21] <atom1> yeah i got errors using deb
[23:19:41] <zultron> So, the base packages are probably similarly named: linuxcnc, linuxcnc-devel, linuxcnc-doc.
[23:20:25] <zultron> Then there are the flavor packages: linuxcnc-flavor-posix, linuxcnc-flavor-rt-preempt, linuxcnc-flavor-xenomai-kernel....
[23:21:12] <atom1> i was gonna try and load the new TP code to test
[23:21:13] <zultron> Depending on what happened during src/configure, those may or may not all need to be built.
[23:21:33] <atom1> i don't think i'll tackle it tonight
[23:21:48] <zultron> atom1, are you talking about UBC3? We've never built .debs from that, and it's not trivial. :)
[23:22:29] <atom1> i don't know what UBC3 is but i was gonna try to load the current work in progress to test
[23:23:03] <zultron> Anyway, the Debian packaging needs to be configured to disable generation of any flavors that weren't built during ./configure;make.
[23:23:46] <zultron> A final tricky point is adding a dependency on the kernel package, including version, for kthread flavors.
[23:24:18] <Tom_itx> skunkworks said he's walk me thru it later on
[23:24:28] <Tom_itx> i've never built one from scratch
[23:24:37] <Tom_itx> i'm in no rush
[23:25:08] <zultron> seb_kuzminsky ^ So, that's the story on packaging. If you decide to take it on, let me know.
[23:26:11] <zultron> Sorry atom1, for some silly reason I thought you were talking to me. :)
[23:26:39] <Tom_itx> likewise
[23:26:58] <Tom_itx> ^^ is atom1
[23:29:17] <Tom_itx> i'm off for today anyway...