Back
[01:13:10] <kwallace> https://www.youtube.com/watch?v=xe5JDyljQBI
[05:49:36] <REEEN> hello guys I have some weird problem here is anyone online ?
[05:50:15] <REEEN> i'm currently setting up a closed loop spindle control
[05:50:24] <REEEN> here is an example of my problem:
[05:51:17] <REEEN> pid command is 10 pid output is 5 and feedback is also 5 that is wrong....
[09:17:30] <pcw_home> Might be correct depending on PID settings (for P = 1 that would be correct)
[09:19:51] <pcw_home> that is with just P=1, PID output would be 1*(command-feedback) = 5 in your case
[09:35:10] <cradek> fwiw, I don't believe in closed loop spindle control being useful
[09:37:03] <fenn> vfd's have hall sensors which make them more or less closed loop; if someone is controlling a DC spindle they might need it
[09:49:02] <pcw_home> I think it mainly makes people happier with their spindle speed displays
[09:50:34] <arrowbook> is the pid or s-curve being used in the update_freq function of stepgen.c,,or they are both used
[09:53:13] <cradek> fenn: specifically I meant with pid in hal. I'm definitely in favor of motor drives maintaining speed.
[09:53:45] <jepler> arrowbook: stepgen can limit acceleration, giving a trapezoidal velocity profile. it has an internal feedback loop similar to pid, too, but that has no tunable parameters.
[10:04:13] <KGB-linuxcnc> 03Chris Radek 052.6 5920630 06linuxcnc 10src/emc/usr_intf/touchy/mdi.py touchy: G64 now takes optional Q * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5920630
[10:04:13] <KGB-linuxcnc> 03Chris Radek 052.7 b0750ee 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b0750ee
[11:36:03] <cradek> pcw_home:
http://www.phoronix.com/scan.php?page=news_item&px=VIA-Embedded-New-PC
[11:38:08] <jepler> boo, no linux video support
[11:38:26] <jepler> I was unlucky enough to have a system with VIA Chrome video chipset 10 years ago, and support was bad then too.
[11:40:32] <cradek> argh
[11:44:16] <jepler> most likely it runs without any acceleration, which would be fine for touchy but not great for axis
[11:49:20] <jepler> dpkg-deb: building package `linux-image-4.1.0-1-rt-amd64' in `../linux-image-4.1.0-1-rt-amd64_4.1.3-1.1_amd64.deb'.
[11:49:33] <jepler> looks like the kernel package from debian testing will build on debian stable (jessie)
[11:54:35] <skunkworks> jessie livecd!
[11:54:57] <skunkworks> I have not tried jessie yet
[11:58:58] <pcw_home> Might be interesting to try the Via but not at $539
[11:59:00] <pcw_home> This is more my price range:
[11:59:01] <pcw_home> http://www.newegg.com/Product/Product.aspx?Item=N82E16856501007
[12:04:14] <jepler> hm, now I'm wondering if you can do realtime hostmot2 + regular networking all over one gigabit interface. I bet none of the cheap ethernet switches honors QoS though.
[12:05:14] <jepler> the driver and the hostmot2 card would have to set the "low latency" flag in the ip header, which they don't do now afaik
[12:06:39] <jepler> https://en.wikipedia.org/wiki/Differentiated_services#Expedited_Forwarding_.28EF.29_PHB
[12:08:10] <skunkworks> pcw_home, does wheezy run on it?
[12:08:52] <jepler> the cheap gigabit port I bought claims: Supports IEEE 802.1p QoS (4 Queues, Strict Mode)
[12:08:55] <jepler> https://en.wikipedia.org/wiki/IEEE_P802.1p
[12:09:33] <pcw_home> I was just thinking about that(getting along with regular traffic) ,
[12:09:35] <pcw_home> the low latency flag is probably pretty easy to add
[12:10:20] <pcw_home> I doubt wheezy will run without a newer kernel (it would not run on the Stream mini)
[12:10:32] <pcw_home> (run on the Liva)
[12:10:37] <skunkworks> pcw_home, should a IEEE-1284 cable work?
[12:10:44] <pcw_home> yes
[12:10:53] <skunkworks> thanks
[12:11:46] <skunkworks> dad just felt the backlash on the cincinati lathe and there doesn't seem to be any... He is thinking of keeping it again..
[12:13:29] <skunkworks> cradek, I think I had changed the G64 parameters - I bet that was why I wasn't getting the small violation.
[12:13:36] <jepler> after a few minutes googling I'm not sure how to set the ethernet PCP field
[12:13:44] <jepler> on linux
[12:14:03] <skunkworks> anyone programmed nfc tags in linux?
[12:14:06] <jepler> oh maybe it's easy
http://stackoverflow.com/questions/13764786/setting-cos-pcp-802-1p-in-ethernet-frame
[12:27:44] <pcw_home> seems like bestt case you would still add a full packet latency due to
[12:27:46] <pcw_home> head of line queuing (but thats only ~12 usec for a 1500 byte packet)
[12:27:47] <jepler> hm have to set up 802.1Q "virtual local area networking" before there's a PCP field to fill -- ethernet frames get an additional 2-byte header
[12:34:10] <jepler> it boots and so far I also get good latency on my laptop, 14.3us max in 1 minute
[12:38:57] <pcw_home> the debian preempt-rt kernel?
[12:40:36] <seb_kuzminsky> nice!
[12:42:13] <jepler> pcw_home: yes
[12:43:42] <skunkworks> wow - that is rtai type numbers
[12:43:55] <skunkworks> but I guess 1 minute isn't really long enough
[12:44:35] <pcw_home> My (ebay test) laptop works fine with Preempt RT as long as you dont change from line to battery power or vice versa
[12:44:38] <jepler> only problem I've spotted so far is that the -headers package is uninstallable due to dependencies not in debian jessie
[12:45:14] <jepler> 31.5us over 12 minutes, including changing from AC to battery and back
[12:46:42] <pcw_home> Good enough for Jazz ^H^H^H^H Ethernet
[12:46:45] <mozmck> that's more impressive
[12:48:20] <pcw_home> WIFI working?
[12:48:31] <jepler> pcw_home: yep
[12:49:15] <pcw_home> (I noticed that Broadcom WIFI causes major latencies at least on the Stream mini)
[12:49:33] <pcw_home> Broadcom is a PITA anyway so best avoided
[12:50:45] <pcw_home> My general impression is that modern (and fast) systems tend to work well with Preempt-RT
[12:59:05] <skunkworks> you are right - that cable worked :)
[13:02:25] <pcw_home> IEEE1284 cables have lower crosstalk and better ground integrity than normal parallel port cables or flat cables
[13:03:01] <pcw_home> (they have a shield wire per signal)
[13:04:20] <skunkworks> ciik
[13:04:22] <skunkworks> cool
[13:06:01] <jepler> 51us latency, but now I'm rebuilding the kernel package at the same time
[13:10:09] <pcw_home> something building kernels does at the very end seems to cause major latencies
[13:14:31] <jepler> I'll make sure and run the latency test to the bitter end, then
[13:42:56] <jepler> hmph, it's topped 100us latency
[14:11:26] <cradek> I don't understand why nondevelopers want to run RIP builds
[14:11:51] <cradek> we work hard to make good packages so they don't have to
[14:14:29] <Tom_itx> what causes following errors on a stepper system?
[14:15:09] <Tom_itx> and you do a fine job of it cradek
[14:15:38] <cradek> oh look he's right here, haha
[14:16:21] <Tom_itx> the sherline is rigid tapping now..
[14:17:42] <cradek> Tom_itx: you made two separate threads with your reply. please pick the most appropriate list when you reply. (this might be your mailreader doing a stupid thing without telling you)
[14:18:16] <Tom_itx> my reply to what?
[14:18:31] <cradek> the release post
[14:18:34] <pcw_home> wrong tom
[14:18:39] <Tom_itx> i don't get on the mail list
[14:18:39] <cradek> oh
[14:18:40] <Tom_itx> :D
[14:18:50] <cradek> we all need globally-unique identifiers
[14:19:00] <cradek> mine is 6a2f7d9a-6365-424c-a95e-f916d3927a77
[14:19:00] <Tom_itx> some like to hide behind them
[14:19:07] <cradek> run uuidgen to make your own
[14:20:04] <Tom_itx> i probably had that scoulding coming anyway...
[14:20:43] <pcw_home> the linuxcnc step generator is a simple velocity mode servo so followings error are possible
[14:21:03] <pcw_home> following errors
[14:21:56] <Tom_itx> i'll have to do some more testing.. i wasn't doing anything crazy with it
[14:22:01] <Tom_itx> only got it once or twice
[14:23:57] <pcw_home> if your limits are really tight you can get it or if you use the built-in driver
[14:23:59] <pcw_home> position mode stepgen and you have significant jitter you can get it also
[14:24:52] <Tom_itx> it could have been the Z axis since it's sitting on the table and not in it's enclosure with the counterweight attached
[14:25:44] <pcw_home> If you use the drivers position mode you need to set the stepgen maxaccel
[14:25:45] <pcw_home> to about 20% more than the axis maxaccel
[14:26:11] <Tom_itx> i think it is
[14:26:27] <Tom_itx> but i set it a long time ago so i'll have to check again
[14:27:28] <pcw_home> Yeah a headroom problem can cause this also (like cannot get to maxvel with current step/dir timings)
[14:28:38] <pcw_home> It would be nice if linuxcnc remember that max ferror for these cases (I know you can do this is HAL)
[14:28:52] <pcw_home> remembered the
[14:31:54] <pcw_home> the drivers hardware stepgen control logic _will_ go crazy and generate FEs
[14:31:55] <pcw_home> if you have significant jitter and you dont bound the stepgens maxaccel
[14:31:57] <pcw_home> This is why I moved to PID run stepgens for Ethernet, much better behaviour
[14:31:58] <pcw_home> when there is significant jitter
[15:12:36] <jepler> pcw_home: with hostmot2 stepgens and pid, is tuning still necessary or is there a formulaic way to determine the pid gains?
[15:19:32] <jepler> (that sound is me thinking that the appropriate feedback still belongs inside the hostmot2 driver, even if it's more complex than a copy of the simple feedback algorithm from our software stepgen)
[16:06:49] <PCW> I dont have a formulaic way except from experience:
[16:06:51] <PCW> FF1 = 1
[16:06:52] <PCW> P ~= servo thread frequency
[16:06:54] <PCW> FF2 ~= 0.00012 to 0.00030 depending on time between read (well DPLL latch) and write
[16:06:55] <PCW> (An approximate guess value of .0002 is probably OK unless you want <100 u inch errors at 6000 IPM )
[16:07:40] <PCW> (in which case you need to tune)
[16:10:52] <PCW> Error could be even smaller except that FF2 is late by one sample
[16:10:53] <PCW> (this is why the TP should output the derivatives, with pipeline delays
[16:10:55] <PCW> fixed rather than generate them with DDT at the HAL level)
[16:13:43] <PCW> That is ideally (IMHO) the TP should give HAL/hardware interpolators the current waypoint and the derivatives to get to the next...
[16:34:51] <jthornton> now to figure out how to drop .3rtapi and the rest of the extensions from the link text for the man pages
[16:43:25] <PCW> FF2 may also depend on the servo period
[16:46:10] <seb_kuzminsky> cradek: Tom Easterday said "I did have a component that was causing the build to fail early but fixed that", i take that to mean he's got a custom component that he's pushing along
[16:50:02] <jepler> jthornton: in shell you can take off a known suffix this way
[16:50:02] <jepler> $ X=foo.bar; echo $X; echo ${X%.bar}
[16:50:02] <jepler> foo.bar
[16:50:02] <jepler> foo
[16:50:22] <jepler> I think make is invoking the shell in your case, so doubling the $ may be necessary
[16:51:06] <jepler> yuck, this fully built rt kernel generated 1.1GB of packages
[16:51:14] <jepler> that'll be slow to upload to the internet
[16:54:16] <jepler> well, tomorrow, I'll have some preempt-rt kernel packages for anyone with a jessie amd64 machine to try out
[16:54:52] <JT-Shop> jepler, can you use a wildcard for .bar?
[16:55:51] <jepler> looks like it
[16:55:51] <jepler> $ X=foo.bar.baz; echo $X; echo ${X%.*}
[16:56:30] <JT-Shop> thanks
[16:57:01] <seb_kuzminsky> i would have used basename for that, but the bash string manipulation seems better
[16:57:29] <seb_kuzminsky> $ X=foo.bar; basename foo .bar
[16:57:34] <seb_kuzminsky> foo
[17:07:09] <jepler> and happily it's a part of posix sh so it's portable
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
[17:07:21] <jepler> ${parameter%word}
[17:07:22] <jepler> Remove Smallest Suffix Pattern. The word shall be expanded to produce a pattern. The parameter expansion shall then result in parameter, with the smallest portion of the suffix matched by the pattern deleted.
[17:13:27] <mozmck> jepler: do you have debug turned on in the kernel? that makes *much* larger packages
[17:16:43] <jepler> mozmck: yes. I didn't change anything about the kernel package, just rebuilt the one from debian testing for debian stable.
[17:17:37] <jepler> (so there's a vanilla kernel package in there too)
[17:17:59] <mozmck> If you use the debian kernel build scripts I think it turns off debug. Otherwise you have to edit the config.
[17:34:41] * jepler finishes his laptop's latency-test at 112us latency over 5 hours
[18:01:18] <jepler> the only remaining problem is that the debian jessie version of the nvidia proprietary kernel module is not compatible with kernel 4.1
[18:28:35] <PCW> I think all versions or Preempt-RT Ive built have complained about nvidia
[18:29:24] <jepler> I haven't tried to use them together lately
[18:43:46] <jepler> whee, nvidia works and no huge latency spike from starting an opengl application using nvidia acceleration (glxgears, anyway)
[20:00:25] <mozmck> If you have an axis with a handwheel and a servo motor, can you make linuxcnc update the position from the encoder when manually moving with the handwheel?
[20:01:01] <mozmck> (the motor drive would have to be disabled of course)
[20:02:05] <jepler> yup, already does that
[20:02:25] <jepler> in machine off mode the amp should be disabled but linuxcnc tracks the position
[20:02:32] <mozmck> hmm.
[20:02:41] <jepler> on the off -> on transistion, the commanded position becomes the feedback position
[20:02:51] <jepler> well in all modes including estop linuxcnc tracks position
[20:03:28] <mozmck> our thc moves the Z independently of Linuxcnc when cutting, and returns control to linuxcnc when not cutting.
[20:04:31] <mozmck> I'm wondering if there is a way to use the step signals coming out of the THC as an encoder to keep linuxcnc updated with the current position?
[20:05:22] <mozmck> This would be with the machine on and running though. Would I get following errors?
[20:07:24] <andypugh> You can arrange not to. Perhaps using “offset”
[20:08:28] <mozmck> I'm not familiar with offset. this is a step and direction drive, so open loop normally.
[20:08:37] <jepler> offset is a hal component
[20:09:58] <mozmck> thanks, I'll look at that.
[20:45:44] <skunkworks> http://www.machsupport.com/forum/index.php/topic,30680.0.html
[21:04:42] <Tom_itx> that would be like putting racing fuel into a yugo
[21:43:18] <jepler> hee hee
http://www.machsupport.com/Mach3Wiki/index.php?title=Rs274ngc.h
[21:47:45] <jepler> (I had gone looking for documentation on making a mach motion plug-in and ran into this)
[21:56:13] <mozmck> I have such documentation if you need it...
[21:57:34] <mozmck> hmm, it is for Mach3, so may not be relevant for Mach4 if that's what you want.