Back
[07:58:35] <skunkworks> pcw_home, pcw, running master for an hour or so to the 7i80
[07:59:03] <skunkworks> terminal scolds me that I don't need watchdog
[08:21:13] <skunkworks> (Wheezy
[09:05:54] <pcw_home> Not sure what the issue is yet but currently wont run more than a minute or two without problems
[09:17:37] <skunkworks> what system?
[09:24:49] <pcw_home> J1800 as always nothing changed except pulling master (AFAIK)
[09:25:01] <pcw_home> Ubuntu 14.04
[09:25:28] <jepler> with git you can return to a specific old version of the code
[09:25:42] <pcw_home> I will have to try that
[09:26:17] <jepler> there are lots of different ways to do it. the simplest may be to use "gitk" to graphically view the history, and choose "reset master branch to here"
[09:26:25] <jepler> to go back to the present, you would "git pull"
[09:26:55] <jepler> warning: if you have modified any files, this will throw away your modifications
[09:27:20] <pcw_home> no mods that have not already been tossed
[09:28:10] <jepler> you might want to use this commandline so it doesn't show you commits from the 2.6 branch (if you checkout 2.6, hm2_eth will of course not be there) gitk origin/2.6..origin/master
[09:28:10] <pcw_home> same troubles on AMD A4-5000 MB so I dont think its hardware related
[09:28:22] <skunkworks> this is the 2 nic version of that motherboard. (plus it has pci to run the 5i25 also ;) )
[09:28:31] <skunkworks> j1900?
[09:29:13] <pcw_home> well this is the MB that ran hm2_eth for 120 days most at 2 KHz
[09:29:30] <pcw_home> J1900 is the quad core
[09:30:47] <jepler> once you find a "good" version, I can walk you through using "git bisect" to find the specific commit that introduced the regression
[09:31:00] <jepler> git bisect is pretty cool
[09:31:09] <pcw_home> I may well have busted something else so I need to experiment some more
[09:31:10] <pcw_home> (I wish I could get wheezy to boot on something)
[09:47:19] <skunkworks> still running
[09:59:55] <pcw_home> OK so unless its specifically related to DPLL access or something else you are not doing but I am,
[09:59:57] <pcw_home> its likely some OS or networking problem that I have somehow generated
[10:05:10] <pcw_home> Thanks for testing
[10:11:39] <skunkworks> I could test your dpll stuff so we get rid of that variable..
[10:14:49] <pcw_home> 7i80hd_16_svst2_4_7i47d.bit ought to be a ~ suitable bitfile
[10:32:25] <pcw_home> Despite misgivings about Biostar, the A68N-5000 worked first time without any
[10:32:26] <pcw_home> fighting with the BIOs and seems to have better latency with Preemt-RT than the J1800
[10:32:28] <pcw_home> seem about as fast as the J1800 though a bit hotter
[10:34:57] <skunkworks> I have had good and bad luck with biostar
[10:36:04] <pcw_home> Yeah, I just swapped the drive from the J1800 and it just worked (had to turn off power management of course)
[10:36:41] <pcw_home> Video seems to have less effect on latency vs the J1800
[10:37:42] <pcw_home> http://www.newegg.com/Product/Product.aspx?Item=N82E16813138412
[10:37:44] <pcw_home> I wonder if the wheezy image will boot on it
[10:42:39] <brianmorel99> pcw: Is the 7i92 getting close to being available?
[11:06:02] <pcw_home> we screwed up on board ordering so they have been set back ~3 weeks so mid/end Oct
[11:15:44] <brianmorel99> I'm almost done ( hopefully ) getting the Preempt_RT patch merged & built for my Jetson TK1. I was thinking of getting the 7i92 and 7190 to play around. Not a rush so know big deal.
[11:55:16] <seb_kuzminsky> i hope joe hildreth sends us a patch!
[12:01:29] <pcw_home> I wonder if really huge setup and hold times affect performance much
[12:25:43] <skunkworks> seb_kuzminsky, my gearshift16 is pretty specific to my machine and was only posted as a reference.
[12:27:05] <skunkworks> it probably could have been done with classic ladder and hal but I could only wrap my head around it programically..
[12:28:43] <skunkworks> gear change is pretty machine specifice so I don't know how someone would think that it should be generic..
[12:29:25] <skunkworks> similar to tool change.. Should there be a 'tool change' componant?
[12:29:29] <skunkworks> I think not..
[12:37:31] <seb_kuzminsky> skunkworks: i partially agree with you
[12:37:51] <seb_kuzminsky> i think there are several things people mean when they talk about gearchangers
[12:38:24] <seb_kuzminsky> some of them are probably so wonky and machine-specific that trying to generalize them is futile
[12:39:00] <seb_kuzminsky> but some of them can probably be made better in linuxcnc
[12:41:57] <seb_kuzminsky> skunkworks: your gearchange16 component takes "commanded spindle speed in", selects a gear for accomplishing that speed, and switches the machine to that gear, right?
[12:42:21] <skunkworks> yes
[12:43:45] <skunkworks> it also does spindle lock because the spindle has to be in a certain gear for that to work.
[12:44:17] <skunkworks> and things like - if you adjust the spindle override - don't shift gears..
[12:46:23] <seb_kuzminsky> yeah, so some of that is certainly machine-specific (driving the gearchange rails)
[12:46:49] <seb_kuzminsky> but some of it might be generally useful (given a desired spindle speed and information about the gearbox, choose which gear the machine should be in)
[12:47:28] <seb_kuzminsky> then you can imagine a generic gearchange interface, like our generic toolchange interface (with 'tool-prep', 'tool-prepared', 'tool-change', and 'tool-changed')
[12:47:47] <skunkworks> sure
[12:48:35] <seb_kuzminsky> but i dont know if that's what everyone's excited about on the mailing list
[12:48:47] <seb_kuzminsky> i guess i should mail them instead of chat here...
[12:50:36] <skunkworks> heh
[12:58:33] <seb_kuzminsky> i'm looking at the gearchange.9 we currently have
[12:59:22] <seb_kuzminsky> you tell it about the gearbox and which gear is selected, and you give it 'speed in', and it gives you 'speed out'
[12:59:56] <seb_kuzminsky> is this for if you have an encoder on the motor shaft but not the spindle, and you want to convert spindle motor speed to spindle speed?
[13:00:18] <seb_kuzminsky> that's the inverse (in a sense) of what skunkworks's comp does
[13:00:40] <skunkworks> You made sense of mine? I can't even make sense of it...
[13:02:04] <Connor> http://linuxcnc.org/docs/html/man/man9/orient.9.html
[13:02:18] <Connor> I've looked this over... and have yet to find a good working example..
[13:02:29] <Connor> who wrote this component?
[13:10:13] <seb_kuzminsky> Connor: michael haberler wrote it
[13:10:36] <Connor> He ever on IRC ?
[13:11:19] <seb_kuzminsky> not here, he left the project
[13:11:45] <Connor> Ugg.. so.. does anyone have any documented USE of this component ?
[13:11:50] <skunkworks> Connor, have you searched the forum? I seem to remember someone using it..
[13:12:11] <skunkworks> or atleast some examples of spindle orient
[13:12:28] <Connor> skunkworks: Not yet.. I looked in the wiki, and online search only to find my own question I sent out a few months ago on the users list.
[13:13:54] <seb_kuzminsky> Connor: looks like he didn't write any docs beyond what's in the orient.9 manpage, and no sample configs
[13:14:09] <Connor> seb_kuzminsky: Yup.. and thusly my problem. :)
[13:14:18] <Connor> and the simulator config sucks.
[13:14:53] <seb_kuzminsky> we do have a sample config called sim/axis/spindle_orient/orient.ini, which claims to show spindle orient capability, but it does not use the orient component....
[13:15:49] <seb_kuzminsky> if you can improve any of this (manpage, sample config) or provide a better config that'd be very welcome
[13:16:43] <cradek> who is ArcEye? I really appreciate his work on the forum:
http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28403-concave-corners#51563
[13:17:02] <seb_kuzminsky> he's pretty active in #linuxcnc too i think
[13:18:27] <cradek> not using that name
[13:20:26] <seb_kuzminsky> maybe i misremembered where i saw his name
[13:20:37] <cradek> or he uses more than one handle
[13:20:46] <cradek> I get lost with the handles
[13:25:17] <Connor> skunkworks: Looking through the forum... like looking for needle in a hay stack..
[13:32:09] <cradek> http://linuxcnc.org/index.php/english/forum/10-advanced-configuration/28344-proper-spindle-orientation-using-26#50958
[13:32:56] <cradek> not that I see anything useful
[13:33:04] <Connor> Yea. nothing useful.
[13:33:36] <cradek> um, what's your question?
[13:34:11] <cradek> I mean, how far are you? what's the exact problem?
[13:34:13] <Connor> Looking for a working example.
[13:34:38] <Connor> What exactly is needed to get it working.
[13:34:50] <cradek> so you haven't started or tried anything?
[13:35:06] <Connor> I played around with it on my personal machine a while back and never was able to get it to work.
[13:35:15] <Connor> I don't remember the specifics..
[13:35:36] <cradek> I suggest you try to get it working, and then if you get stuck you'll have more specific questions
[13:35:46] <cradek> the motion manpage says what the output signals are
[13:36:32] <cradek> the orient manpage might help
[13:36:36] <cradek> looking at orient's source might help
[13:37:59] <Connor> cradek: At issue is.. I don't even know where to start.. and if this was being used for my personal machine.. I could tinker for hours on end.. but.. This is for Pete, and I have to drive 35 minutes to his house to help.. and sit in his shop to try to figure this out.. I was just hoping to find a working config to see how to get started with it.
[13:40:06] <cradek> is this for a toolchanger that needs to orient the drive dogs but doesn't have a mechanical orient pin?
[13:40:37] <Connor> cradek: Correct
[13:40:46] <cradek> yuck, I hate those
[13:42:52] <pcw_home> It seems relatively straight forward, but does expect a PID loop controlling spindle position
[13:42:54] <pcw_home> dont know how tricky it is to drive Petes Modbus VFD with a velocity command from a PID component
[13:43:44] <cradek> vfds can't really hold position, so these systems always seem shaky to me
[13:44:02] <cradek> a pin or a heart shaped or ramped cam seems so much better
[13:44:32] <pcw_home> how accurate does it need to be?
[13:44:43] <cradek> depends how sloppy the drive dogs are
[13:44:52] <cradek> ought to hold within a few degrees probably
[13:45:19] <skunkworks> some vfd's have an orient option...
[13:45:27] <cradek> or you could just take them off, heh
[13:45:51] <cradek> skunkworks: I've seen jog (move slow, maybe with reduced torque), but not orient. how could they possibly know how to orient?
[13:46:28] <archivist> absolute encoder or index pules
[13:46:52] <cradek> assuming no belt between the motor and spindle
[13:47:26] <cradek> I'd think any vfd feedback is normally on the motor, not the spindle
[13:47:50] <cradek> maybe some are direct (none of mine are)
[13:48:26] <pcw_home> this has an encoder on the motor that belt drives the spindle (spindle is 1/2 motor speed)
[13:48:49] <archivist> iirc his is 2-1 so would be 180 degs at the spindle, that should be ok anyway
[13:48:50] <pcw_home> (toothed belt)
[13:49:43] <cradek> are the dogs the same size?
[13:50:04] <cradek> if you have two possible orientations you don't have any benefit for boring tools etc
[13:50:07] <Connor> I think his VFD might have a position option.. but.. it has no encoder feed back.
[13:50:21] <Connor> no, his dogs are not the same. only 1 position is correct
[13:50:37] <Connor> which is the other reason for the 180 out sensor
[13:51:00] <cradek> what sensors do you have?
[13:51:27] <Connor> Differential encoder with index ON the motor, 180 sensor on the spindle.
[13:51:42] <Connor> it use to use a resolver instead of the encoder.
[13:52:03] <cradek> if using hostmot2, you could use that sensor as index mask
[13:52:04] <Connor> they somehow did it using that.. no locking mechanism or anything.
[13:52:24] <Connor> We are.. already have that setup thanks to pcw_home
[13:52:32] <cradek> cool
[13:52:39] <Connor> custom firmware even.
[13:52:49] <cradek> boo
[13:56:27] <Connor> It is what it is.
[13:57:00] <Connor> I guess maybe we could feed the VFD the encoder information.. but.. not sure how to get it the MASKED index...
[14:06:47] <skunkworks> Connor,
http://linuxcnc.org/index.php/english/forum/30-cnc-machines/26178-cincinnati-axis-spindle-question?limitstart=0
[14:11:37] <Connor> okay.. that's odd.. the spindle has encoder input.. but.. only A and B. No INDEX.
[14:13:36] <Connor> skunkworks: Looks like he refers to the stupid simulator again..
[14:18:27] <skunkworks> what is wrong with that? not a good starting point?
[14:19:17] <Connor> andy isn't using the orient component.
[14:19:44] <Connor> and take a look at the hal and ini file of the orient simulator..
[14:19:56] <skunkworks> no - he is also using it as a rotory axis.. (or trying to)
[14:21:26] <Connor> Maybe I can check with Andy when he logs in.. He may have gotten the orient comp to work at some point also.
[14:25:22] <skunkworks> it is really cool how you can apt-get install mesa flash now.. awesome work
[14:25:32] <cradek> yay!
[14:25:52] <skunkworks> things are really becoming painles..
[14:25:57] <skunkworks> painless
[14:26:25] <skunkworks> Connor, if robh is around - he has also done spindle orient with a vfd
[14:26:50] <Connor> okay. I'll keep an eye out for him
[14:27:23] <skunkworks> and so did the mazak...
[14:27:38] <Connor> I guess the question is.. what do you DO with the orient-pid.command output ?
[14:28:19] <Connor> the VFD isn't even being used with PID.. it's simply setup as a open loop spindle with encoder feedback.
[14:31:26] <cradek> well you need a closed loop and a pid to orient it
[14:32:07] <cradek> have you read all the words in the orient manpage?
[14:32:26] <alex-GN> hi guys, any devoloper working on remaping online?
[14:32:39] <cradek> I notice the orient component doesn't cause an index reset, so index mask doesn't help you
[14:32:50] <cradek> alex-GN: hi, go ahead and ask the real question
[14:33:27] <alex-GN> hi, I just tested today the new remaping functions on a real machine,
[14:33:33] <Connor> index-mask is handled at the mesa level. makes it look normal
[14:33:57] <alex-GN> for using a rack -type toolchanger
[14:34:20] <alex-GN> everything works great until you abort execution of the program
[14:34:31] <alex-GN> after the machine stops at the very point you interrupted execution
[14:34:43] <alex-GN> it will move to the last line read by the interpreter
[14:34:52] <alex-GN> in my case for example line 10500
[14:35:09] <alex-GN> even if i aborted the program at line 5000
[14:35:23] <cradek> you get an extra move after you abort?
[14:35:27] <alex-GN> yes
[14:35:30] <alex-GN> exactly
[14:35:40] <cradek> what version are you running?
[14:36:06] <alex-GN> the move goes exactly to the coordinates where the machine should be in the last line read
[14:36:30] <alex-GN> tried both on 2.6.2 and 2.6.1
[14:36:42] <cradek> how are you aborting?
[14:36:55] <alex-GN> by pressing escape on the keyboard
[14:37:04] <cradek> what gui?
[14:37:16] <alex-GN> axis
[14:37:34] <cradek> hmm!
[14:37:56] <Connor> isn't there a on_error file that gets run on aborts ?
[14:38:02] <cradek> could you assemble a sim config that shows this behavior?
[14:38:21] <cradek> Connor: good question, I'm not sure
[14:38:38] <cradek> I also use remap of M6, but I have not seen this problem
[14:38:45] <alex-GN> I have assambled a "sim" config on the pc i am writing now
[14:39:01] <cradek> excellent. can you tar it up and put it online somewhere for us?
[14:39:08] <alex-GN> shure
[14:39:11] <alex-GN> 1 moment
[14:41:02] <alex-GN> https://www.dropbox.com/s/3oa5jve43p7eaw5/lc-1020.tar.gz?dl=0
[14:41:17] <Connor> I have a on_abort.ngc file that gets fired on aborts...
[14:41:45] <alex-GN> yes, i use the standard on_abord.ngc given in the example
[14:41:57] <skunkworks> pcw_home, wrote 7i80hd_16_svst2_4_7i47d.bit to the card and running it. (with current config)
[14:42:05] <alex-GN> and also reset_state.ngc
[14:42:38] <alex-GN> it executes on_abort.ngc shurely because I tested by writing messages to axis
[14:42:54] <alex-GN> the m2 in the reset_state.ngc makes no difference
[14:45:12] <cradek> probe_parport: dlopen: /home/cradek/emc/rtlib/probe_parport.so: cannot open shared object file: No such file or directory
[14:45:21] <cradek> not quite purely a sim
[14:45:29] <Connor> nope.
[14:46:07] <alex-GN> yes, it-s a config for running on a parallel port
[14:46:16] <alex-GN> works on my computer without any issue
[14:47:17] <Connor> Going to be hard to test if it's not pur sim
[14:48:40] <alex-GN> ok, i'll try assembling a pure sim config
[14:49:29] <cradek> I hacked out parport stuff, and now I'm stuck on:
[14:49:29] <cradek> Embeded tab command "halcmd loadusr -Wn gladevcp gladevcp -c gladevcp -x 67109006 -c gladevcp racktoolchange.glade" exited with error: 1
[14:49:38] <Connor> I have a simulated carousel toolchanger.. but.. I've not tested it in a program yet.. requires too many sensor checks..
[14:50:19] <cradek> aha, installing python-xlib fixed it
[14:50:28] <cradek> now I get AXIS with two extra indicator things
[14:50:44] <cradek> but won't come out of estop (because I hacked that stuff out)
[14:50:57] <cradek> I'll wait for you to work up a sim, thanks
[14:51:11] <cradek> alex-GN: once you do that it might be best to directly file a bug report with the sim config as an attachment
[14:51:29] <cradek> saying just what steps to take to reproduce the problem
[14:52:02] <cradek> bug tracker here:
http://sourceforge.net/p/emc/bugs/
[14:52:56] <alex-GN> no need to wait for the sim
[14:53:08] <Connor> >
[14:53:09] <Connor> ?
[14:53:21] <alex-GN> i just tested the very same thing with the sim config that comes with version 2.6.2, racktoolchange
[14:53:35] <alex-GN> everything is identical
[14:53:41] <cradek> oh! that's great
[14:53:56] <cradek> please do file a bug report on the tracker, mark it as 2.6
[14:54:00] <alex-GN> ok, the toolchange files are not identical but the behavior is identical
[14:54:27] <alex-GN> shure, i will try to sort this out and resolve the issue
[14:54:33] <alex-GN> hopefully i can :)
[14:55:46] <cradek> that would be great, if you can directly fix it, here's how to contribute the change:
http://linuxcnc.org/docs/2.6/html/code/Contributing-to-LinuxCNC.html
[14:56:42] <Connor> Can you upload your gcode file ?
[14:57:00] <Connor> I just tested it.. and it works fine.. but.. my gcode file was stupid simple.
[14:57:18] <Connor> and I can't recall if this is a STOCK sim tool rack.. or one I modified..
[15:01:29] <alex-GN> shure
[15:01:30] <alex-GN> one moment
[15:02:18] <alex-GN> https://www.dropbox.com/s/dxaz5hyhe6i7hqx/3D%20Roughing%201.ngc?dl=0
[15:02:43] <alex-GN> the tool rack i have also modified but in the stock sim the problem persists
[15:02:57] <alex-GN> i would look into the stdglue python module
[15:05:11] <Connor> Stops dead in it's tracks for me.
[15:05:36] <Connor> Using stock SIM rack tool change.
[15:05:47] <Connor> with your program.
[15:06:00] <Connor> I'm running 2.7.0-pre something..
[15:07:10] <alex-GN> hmmm... i can also try on 2.7.0 pre-2
[15:09:03] <Connor> Wait...
[15:09:08] <Connor> it is doing something strange.
[15:10:37] <Connor> Yea.. that's messed up.
[15:10:53] <alex-GN> 2.7.0_pre-0 has the same behaviour
[15:11:10] <alex-GN> if running the program without stopping it, the machine works ok
[15:11:22] <alex-GN> tested today
[15:11:27] <Connor> Not sure if it goes the the very last line or not.. but.. the tool does "jump" to a new location
[15:11:40] <alex-GN> i took some time
[15:11:51] <alex-GN> it jumps to exactly the last line read by the interpreter
[15:12:45] <Connor> Interesting.
[15:12:56] <Connor> Does the MACHINE move ?
[15:13:02] <alex-GN> yes
[15:13:07] <alex-GN> in linuxcnc status
[15:13:10] <Connor> Wow. That's BAD.
[15:13:18] <Connor> that can cause some major damage.
[15:13:18] <alex-GN> it jumps extactly to the read-line parameter
[15:13:22] <alex-GN> yes
[15:13:37] <alex-GN> i have been luck today while testing,
[15:13:49] <alex-GN> had the hand over the hard wired estop ;)
[15:14:17] <alex-GN> it is interesting, the machine stops for 1-2 seconds before moving to this position
[15:14:47] <alex-GN> spindle and collant turn off like expected
[15:15:23] <Connor> Pause and Stop even cause it...
[15:15:25] <Connor> Not good.
[15:17:07] <Connor> Confirmed it's something with remap.. doesn't happen when testing that program on normal axis sim..
[15:19:35] <alex-GN> i know
[15:19:51] <alex-GN> if i remove the M6 the program works ok,
[15:20:00] <alex-GN> also when aborting, it's behaving normal
[15:25:08] <alex-GN> ok, i have read a little the stdglue.py, it cannot possible host the bug
[15:25:31] <alex-GN> i think the bug lies somewhere deep in the c code part of linuxcnc
[16:07:25] <alex-GN> anybody can point to the source file containing the interpreter abort procedure?
[16:07:32] <alex-GN> sequence?
[16:12:04] <jepler> alex-GN: somewhere in src/emc/rs274 but beyond that I'd have to search for myself
[16:12:22] <alex-GN> thanks, i am searching there :)
[16:13:23] <alex-GN> the remap bug must be located somewhere in this functions
[16:13:49] <alex-GN> queue is not complettly cleared or something
[17:30:43] <PCW> Ahh Wheezy hybrid ISO will boot on A68-5000 (but not even try on D525)
[18:00:44] <skunkworks> PCW, is it working on wheezy?
[18:03:03] <skunkworks> I need to find the link to your config that tickles the dpll stuff.
[18:03:10] <skunkworks> I can test that tomoorw
[18:06:57] <PCW> looks like a driver issue (broken when updated to Ubuntu 14.04)
[18:12:18] <skunkworks> nic driver?
[18:13:28] <PCW> Well two MBs with RTK 8111 are busted (and worked with Ubuntu 12.04) USB Ethernet works better than RTK8111 currently
[18:42:16] <CaptHindsight> I wonder if Intel did something that requires a newer kernel
[18:43:24] <PCW> I think its a realtek driver issue (or Ubuntu poking at the interface when it shouldnt)
[18:43:38] <CaptHindsight> so the NIC driver
[18:43:52] <PCW> driver or Ubuntu
[18:51:14] <skunkworks> yeck
[18:57:40] <PCW> what do you use as a text editor on wheezy?
[18:58:41] <micges-dev> use geany
[18:59:04] <PCW> ok thanks
[19:00:40] <skunkworks> the one installed is called mousepad
[19:00:44] <PCW> hmm not there
[19:02:27] <skunkworks> PCW, ^
[19:18:52] <PCW> skunkworks: have you tried installing linuxcnc from the buildbot images?
[19:19:13] <skunkworks> I have not - only the installed and rip
[19:20:00] <PCW> I thought I followed the instructions but (to fetch wheezy preemt-rt master)
[19:20:02] <PCW> but i just got 2.6.3
[19:21:04] <skunkworks> master will allow you to build for the preempt-rt..
[19:21:07] <skunkworks> oh
[19:21:11] <skunkworks> I see what you are saying
[19:23:06] <PCW> trying to save time. I'll probably just build and RIP
[19:31:12] <PCW> btw Wheezy/RTAI seems acceptable on the A68-5000 ~15 usec base.30 usec servo thread jitter
[19:31:43] <PCW> not bad for a $69 quad core MB
[19:33:17] <skunkworks> and the usb's work!\
[22:09:19] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 fef1a62 06linuxcnc 10docs/src/hal/comp.txt docs: document some missing declarations in the comp tool * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fef1a62