Back
[01:40:34] <cradek> Jymmm: pretty sure it's /dev/fd0
[02:02:53] <Jymmm> cradek: Thanks
[04:42:54] <Guest155> hello
[09:03:55] <ilya_> index of 2.00005 = 2, 2.0001=2. 2.00011 = ?
[09:33:59] <piasdom> g'mornin all
[10:29:11] <EbiDK> EbiDK is now known as EbiDK|AWAY
[12:05:35] <bernd_l> hi
[12:06:36] <bernd_l> i am trying to post a mail to the emc newsgroup <emc-user@lists.sourgeforge.net> , but it didn`t work?
[12:06:54] <archivist> have you joined the list
[12:07:12] <bernd_l> yes
[12:07:30] <bernd_l> i wrote something 4 days before
[12:07:56] <archivist> sourceforge has its bad days :(
[12:08:17] <bernd_l> shit :)
[12:08:20] <archivist> you can ask in here we will answer if we can
[12:08:29] <bernd_l> ok
[12:08:55] <bernd_l> when i put on my machine it occurs the following error:
[12:09:23] <bernd_l> following error on joint 0
[12:09:38] <bernd_l> even there is no movement
[12:10:18] <bernd_l> how can I deactivate this error message
[12:10:20] <bernd_l> ?
[12:10:28] <archivist> I did see a message to that effect and you have had a reply
[12:10:51] <bernd_l> oh where I couldn`t find it
[12:12:55] <bernd_l> I got a mail from mail delivery system?
[12:13:19] <archivist> I can see the online list is lagging but it should have been sent to you
[12:15:57] <SWPadnos> you can't deactivate the message
[12:16:15] <SWPadnos> if it still happens when you set FERROR to 100, then there's something else wrong
[12:17:55] <bernd_l> yes it happens with FERROR = 100 as well?
[12:18:19] <SWPadnos> I saw your mail, that's how I know ;)
[12:18:38] <SWPadnos> can you put your ini file and hal files on
http://pastebin.ca?
[12:20:44] <bernd_l> ok
[12:21:21] <bernd_l> when did you get the last mail from u<emc-user@lists.sourgeforge.net>?
[12:21:43] <SWPadnos> about 15 minutes after you posted your question
[12:21:50] <SWPadnos> from Sven Wesley
[12:22:13] <SWPadnos> he asked about whether you use shielded cable for your encoders
[12:29:47] <bernd_l> I use SSI Standard not a incremental counter and the cable is shielded yes!
[12:30:58] <bernd_l> the driver for the hardware are self-made :)
[12:39:00] <SWPadnos> uh-oh :)
[12:40:33] <archivist> too many "SSI Standard"'s on google what is it
[12:40:51] <SWPadnos> it's a serial data standard used for encoders
[12:41:06] <SWPadnos> I think it's more or less SPI, with some more specific data format
[12:43:58] <bernd_l> have a look here
http://www.sick-stegmann.de/sickstegmann_de/about/eigenmarken/ssi/de.toolboxpar.0005.file.tmp/SSI_Produktinformation_Englisch.PDF
[12:44:27] <SWPadnos> heh. I have a Stegmann encoder manual :)
[12:45:08] <SWPadnos> oh. is this an absolute encoder?
[12:45:17] <bernd_l> yes
[12:45:23] <SWPadnos> ah-ha
[12:45:31] <bernd_l> it`s more or less spi
[12:45:52] <SWPadnos> how are you starting EMC?
[12:46:24] <bernd_l> emc ...inifile comand from shell
[12:46:28] <SWPadnos> there isn't really any support for absolute encoders in EMC, but you may be able to work around that if you're careful
[12:46:29] <SWPadnos> ok
[12:46:40] <SWPadnos> I guess I mean how does it go to the "machine on" state
[12:47:12] <SWPadnos> if your encoder feedback is valid when EMC is in estop or estop reset, it should work OK
[12:47:36] <SWPadnos> (emc makes commanded position track feedback position while in machine on, and maybe estop as well)
[12:47:44] <SWPadnos> err, machine off Imeant
[12:47:47] <SWPadnos> I meant
[12:48:01] <SWPadnos> (sorry - just starting on my first coffee of the day)
[12:48:42] <bernd_l> oh :) no problem
[12:49:31] <bernd_l> the machine works, if i put it on and start a programm with fast movements
[12:50:07] <SWPadnos> you should check your feedback with halscope
[12:50:31] <SWPadnos> set halscope to trigger on a following error, or on the motor enables going false
[12:50:45] <bernd_l> after a while the error occcurs spontaneous
[12:51:22] <SWPadnos> yeah, that tells me that something is wrong with the encoder readback
[12:51:44] <bernd_l> ok ;)
[12:51:47] <SWPadnos> either something is getting one bit off, or you're getting FFFF / 0000 readback sometimes
[12:52:21] <bernd_l> in halscope i didn`t see anything
[12:52:26] <SWPadnos> I don't know why it would be better with faster movement
[12:52:28] <SWPadnos> hmmm
[12:53:09] <cradek> if you trigger on following error, you will see what causes the following error
[12:53:26] <bernd_l> yes
[12:53:33] <cradek> ok then what is it? :-)
[12:54:04] <bernd_l> the ferror is between 1.7 and -2
[12:54:06] <cradek> trigger on axis.N.f-errored
[12:54:29] <cradek> 1.7 and -2 what? what are your units?
[12:54:59] <cradek> if mm, that's a huge error and you need to tune your pid loop
[12:55:52] <SWPadnos> bernd_l, when it happens spontaneously, is that only when moving, or does that also happen when it's supposed to be motionless
[12:55:54] <SWPadnos> ?
[12:56:20] <bernd_l> both
[12:56:38] <bernd_l> during the movement it occurs after about 5 minutes
[12:56:54] <cradek> by the way, your messages did go to the list. there were no answers.
[12:57:05] <bernd_l> but motionless after 5 sec
[12:57:20] <SWPadnos> there was one answer to the first message, I didn't see a second message from bernd
[12:57:41] <cradek> Subject: [Emc-users] joint 0 following error
[12:57:44] <cradek> Date: Wed, 29 Jul 2009 11:27:05 +0200
[12:58:16] <SWPadnos> and a reply from Sven Wesley 15 minutes later
[12:58:29] <cradek> oh, right
[12:58:40] <SWPadnos> but nothing since :)
[12:58:49] <cradek> that's because there is not enough information in the question to give an answer
[12:58:51] <bernd_l> my in-box is still empty :)
[12:59:01] <cradek> well, other than a guess
[12:59:06] <SWPadnos> yeah
[12:59:20] <SWPadnos> my guess is that there's a glitch in reading the encoder value, which triggers the following error
[12:59:50] <cradek> if the ferrors are between 1.7 and -2 (mm? inch? mile?) it may just be an untuned loop
[12:59:51] <bernd_l> oohh
[12:59:56] <bernd_l> mm
[12:59:57] <cradek> my questions are not getting answered
[13:00:00] <cradek> ok
[13:00:04] <cradek> 2mm is WAY WAY too large
[13:00:04] <bernd_l> sorry
[13:00:06] <cradek> you need to tune
[13:00:19] <cradek> you may have more than one problem, but that is one of them
[13:00:20] <SWPadnos> he said in the email that the errors still occur with FERROR and MIN_FERROR set to 100
[13:00:47] <bernd_l> yes
[13:00:55] <bernd_l> thats strange
[13:01:04] <cradek> ok, then we need a plot of commanded and feedback positions and ferror, when the ferror happens (when you get a trigger on axis.N.f-errored)
[13:01:06] <SWPadnos> is the machine actually moving when the error occurs, or is it stationary?
[13:01:19] <cradek> then we don't have to guess
[13:01:33] <cradek> guessing is stupid when we have diagnostic tools
[13:01:45] <bernd_l> ok
[13:01:52] <bernd_l> what have I to do?
[13:02:04] <bernd_l> instructions please :)
[13:02:26] <cradek> make us a screen shot of halscope showing the things I said above
[13:02:47] <bernd_l> ok just a moment
[13:12:06] <Jymmm> buenos días
[13:14:29] <bernd_l> i am still woking :)
[13:14:37] <cradek> great
[13:14:48] <cradek> it can be hard to capture this kind of thing but it's worth it :-)
[13:16:50] <bernd_l> i can´t believe it, it works fine !!
[13:17:05] <bernd_l> there´s no error
[13:20:07] <cradek> if you have halscope set up to trigger on f-errored, just let it run. the error will be back.
[13:21:51] <bernd_l> ok I have it
[13:22:03] <cradek> ok good
[13:22:12] <cradek> take a screen shot of scope and put it on imagebin.ca or the like
[13:22:33] <cradek> make sure you set up the scales and time base so we can see what's going on
[13:30:43] <bernd_l> ohh i forget the position-cmd
[13:30:53] <bernd_l> i´ll try another one
[13:32:15] <bernd_l> i put it on imagebin.ca anyway .. the next picture ..
[13:33:49] <bernd_l> will come soon
[13:33:55] <alex_joni> bernd_l: we also need the link from imagebin.ca
[13:34:01] <alex_joni> to be able to look at the picture ;)
[13:34:17] <alex_joni> like this:
[13:34:18] <alex_joni> http://imagebin.ca/view/LXJk8x7.html
[13:34:54] <alex_joni> f-error reaches 1 in your picture
[13:38:24] <SWPadnos> as you can see, the joint feedback position jumps by about 4000 (units)
[13:39:04] <SWPadnos> is this a 12-bit/rev encoder?
[13:39:59] <SWPadnos> (depending on scaling and units, this kind of error can be due to incorrectly interpreting the turns counter and the position within the turn)
[13:41:30] <bernd_l> http:12 bit yes, but it´s configurable
[13:42:09] <bernd_l> but this is the case!!
[13:42:35] <bernd_l> i will check this
[13:42:43] <bernd_l> thanks a lot :)
[14:01:59] <cradek> yep unless the machine moved 2 meters in a msec, your feedback is incorrect
[14:05:56] <SWPadnos> 4 meters - that was closer to 2 divisions at 2k per
[14:06:10] <SWPadnos> that's a fast machine!
[14:07:14] <cradek> what driver is reading this encoder?
[14:08:11] <bernd_l> I wrote it by my self ;)
[14:08:17] <cradek> ah
[14:08:21] <cradek> it doesn't work right, heh
[14:08:43] <bernd_l> it isn`t proved yet ;)
[14:08:56] <archivist> its proved wrong
[14:08:58] <archivist> :)
[14:09:48] <cradek> if you had disabled following error checks, your machine would have worked very hard to instantly move 4 meters
[14:10:08] <skunkworks_> ouch :)
[14:10:09] <archivist> bang
[14:11:09] <bernd_l> ok ok i`m still a beginner ...
[14:11:32] <SWPadnos> you're doing quite well, don't let us stop you :)
[14:12:15] <bernd_l> i can´t stop this, is´s my final practise!!
[14:12:45] <bernd_l> the machine have to work!! sais my boss...
[14:12:58] <SWPadnos> heh
[14:13:17] <archivist> most of us are still practising
[14:13:34] <SWPadnos> are you using amicrocontroller to read the SPI data, or is it a HAL component (reading from the parallel port or something)?
[14:17:37] <bernd_l> ssi data is emulated by an BoschRexroth controller ECODRIVECs
[14:18:07] <bernd_l> the data is read by a PCI-Card ADDI-DATA 1710
[14:18:08] <SWPadnos> what's the update rate?
[14:18:15] <SWPadnos> oh, cool
[14:18:59] <bernd_l> 1 ms - i´m not sure
[14:19:17] <SWPadnos> ok
[14:19:23] <jepler> you wrote a HAL driver for this card, then?
[14:19:46] <SWPadnos> that's something to check. you probably don't want to run the PID loop any faster than your feedback channel can provide new data
[14:20:36] <Valen> I wonder if that kind of error is in the data form the encoder
[14:20:48] <Valen> it sounds like a dodgy connection somewhat
[14:20:48] <SWPadnos> it's possible
[14:21:15] <Valen> it'd be odd i'd think to have the encoder working 99% of the time and it be a software problem ;->
[14:21:27] <SWPadnos> bernd_l, in your HAL driver, you may want to add a parameter that outptus the raw SSI data (if it's available), or the raw register readback value
[14:21:37] <cradek> if you cursor over the plot in halscope you can see the exact numbers - maybe you can see whether it's a single bit error
[14:21:44] <Valen> especially if it was software written by somebody other than me
[14:21:51] <SWPadnos> then you can plot that in halscope also, to see if it's the hardware or the software that's making that spike
[14:22:10] <cradek> good idea
[14:22:42] <cradek> if you have sign-extension, check your rollovers etc too
[14:24:25] <bernd_l> sorry i was absent
[14:24:36] <SWPadnos> you can read back :)
[14:26:21] <bernd_l> ok
[14:26:26] <bernd_l> step by step
[14:26:46] <bernd_l> i don´t get it
[14:27:26] <bernd_l> a dodgy connection?
[14:27:54] <Valen> a hardware problem
[14:27:54] <SWPadnos> a couple of possibilities
[14:27:56] <Valen> not softeare
[14:28:45] <SWPadnos> it could be software - if the software does word size extension then the rollover detection might be wrong
[14:29:01] <bernd_l> i try another controler
[14:29:19] <SWPadnos> think about my suggestion of adding a "raw read" parameter to your HAL driver
[14:29:29] <SWPadnos> that way, you can see if the data is correct or not
[14:29:41] <SWPadnos> that tells you which side of the PCI (or ISA) bus the problem is on
[14:29:49] <bernd_l> ok
[14:29:52] <SWPadnos> (the outside or the CPU :) )
[14:30:10] <Valen> it could be emi in the wires too no?
[14:30:24] <bernd_l> i´ll add an halpin with the rawdata
[15:10:50] <geo01005> has anybody used the GRAFCET sections in classicLadder?
[15:12:42] <cradek> not me - only bits and s32
[15:13:44] <geo01005> I noticed in the docs that there is some mention of the GRAFCET functionality not working quite right yet.
[15:15:42] <cradek> I tried to mess with it once, but I had no clue how to use it
[15:17:23] <geo01005> I suppose I'll just do it with the ladder stuff.
[15:19:55] <bernd_l> hopefully i´ll meet you tomorrow bye :)
[15:55:14] <CWC> goodmorning
[15:55:33] <BJT-Work> almost lunch here
[15:56:18] <CWC> here too i guess
[15:58:24] <CWC> love emc2, but i am a python newbie. having trouble debugging python in emc2. there is no way to get a shell in emc, is there?
[15:58:50] <CWC> a python shell, like idle?
[15:59:30] <BJT-Work> to just run a python program?
[15:59:52] <CWC> no, to debug
[16:00:46] <BJT-Work> did you check dmesg for the debug info you need?
[16:01:43] <cradek> CWC: say what problem you're trying to solve
[16:03:04] <CWC> trying too. i just "finished" a python script, and its large and twisted. some widgets are not being displayed.
[16:03:19] <CWC> but they are if i run in idle under linux or win
[16:03:26] <CWC> just not under emc
[16:04:08] <CWC> idle gives me a shell in the scope of the running application, that i can debug from.
[16:04:42] <CWC> emc is waiting for the app to finish, so i dont really know how to debug in emc2.
[16:05:57] <BJT-Work> can you run the app from a terminal window?
[16:06:08] <CWC> i thought there might be a way to do this?
[16:07:17] <CWC> yep, works fine, under windoze and in linux shell. not in emc2
[16:09:08] <CWC> its my fault, i tested under emc2 in the beginning, 500 lines of code later, some Tkinter.Listbox's and Entry's are not displayed.
[16:10:13] <geo01005> this is for a pycvp widget?
[16:10:19] <geo01005> pyvcp
[16:10:23] <CWC> i created a tiny app that uses the same widgets the main app uses, it works.. so its one of the 495 lines
[16:11:09] <CWC> no, (i dont think so)
[16:11:46] <CWC> not sure. i am not importing pyvcp. so i think thats a no.
[16:12:01] <CWC> i am creating a turning app for my lathe
[16:12:19] <CWC> enter the data and it generates the gcode
[16:12:38] <CWC> does turn, face bore, drill, cutoff
[16:12:59] <BJT-Work> do you know how to spit the g code directly into Axis?
[16:13:50] <CWC> yep, thats what i am doing, and if i exit without action, i just print 'M2'
[16:14:16] <CWC> back to emc
[16:14:19] <jepler> how are you starting your program?
[16:14:29] <BJT-Work> ok, didn't know if you knew about these or not
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators
[16:14:55] <jepler> if it's with "loadusr", then you should be able to run it in the terminal or in your favorite environment
[16:15:06] <CWC> yes sir, i read those
[16:17:06] <jepler> if you're embedding them in axis with ~/.axisrc or whatever, then set your GUI to 'dummy', then start axis inside the terminal or your favorite environment
[16:17:28] <jepler> but axis has to (A) be run in the directory of the inifile and (B) with the commandline argument -ini your.ini
[16:19:09] <CWC> i was using the fools approach, i am pretty new to python and emc2
[16:19:43] <CWC> i am just running the app.py as a gcode file, using FILTER
[16:20:01] <CWC> or as a filter
[16:20:32] <CWC> just cant find a way to debug once its running in emc
[16:21:09] <CWC> it dont think it will work, and i am wasting all of your time. sorry.
[16:21:25] <alex_joni> eh, don't give up that fast ;)
[16:22:17] <CWC> im not, i think i need to explore what jepler said
[16:22:31] <alex_joni> CWC: you should be able to run it stand alone
[16:22:38] <alex_joni> and it should return the g-code to stdout
[16:22:52] <CWC> true, works great.
[16:23:03] <CWC> in windows and my preferred OS
[16:23:11] <jepler> so your program works if you run 'python myfilter.py > mygcode.ngc' at the terminal, but misbehaves when you open myfilter.py in axis?
[16:24:06] <CWC> hold on i have emc on VNC at the moment, ill try
[16:25:01] <CWC> typically i dont run from the terminal. run from icon
[16:25:18] <alex_joni> so where does the output go?
[16:25:27] <alex_joni> I mean how do you check if the g-code is ok?
[16:25:32] <BJT-Work> if you run from a terminal then you will see your error msgs
[16:25:55] <CWC> output is Tkinter widgets. ok trying now...
[16:26:17] <alex_joni> explain "output is Tkinter widgets" ?
[16:27:14] <CWC> misspoke, the app generates the code from data in the widgets.
[16:30:32] <CWC> @jepler - yes, it works from the command line
[16:31:15] <CWC> it works in emc too, just many widgets are not displayed.
[16:31:54] <CWC> seems like just Tkinter.Entry(s) are missing
[16:32:08] <geo01005> emc calling a different version of python?
[16:32:35] <CWC> now thats been on my mind and i am not sure..
[16:33:06] <CWC> i installed from LiveCD
[16:34:09] <CWC> but i havent checked out the pythonic details yet
[16:36:32] <CWC> python reports 2.5.2 in terminal
[16:37:14] <CWC> i developed it under 2.4.4 TK version 8.4
[16:37:35] <CWC> have to go look what emc is using
[16:42:11] <CWC> its most certainly some bugs in my app. i created a new test app that uses the same widgets and they are displayed fine.
[16:44:38] <CWC> i was looking for a way to debug like in 'Idle'
[16:45:00] <jepler> I can't imagine how to run your program both in your debugging environment and from inside axis's "filter"; even if you could, it would probably just make the buggy behavior evaporate.
[16:45:56] <CWC> agreed, i dont want both, i was looking for some debugging tools in emc2.
[16:46:56] <CWC> it runs in the IDE, or commmand line. but has problems in emc.
[16:47:22] <CWC> im trying to figure out how to debug
[16:48:07] <CWC> i could comment out stuff, until i fell over the problem.
[16:48:44] <CWC> i dont think i can do what i was asking for.
[16:49:22] <jepler> I usually do debugging by adding print statements and runing from a terminal
[16:49:31] <CWC> yep me too.
[16:49:40] <jepler> (for python code, anyway)
[16:50:23] <CWC> idle allows you to interact with the running application
[16:51:48] <CWC> in the code - self.gCodeWindow = Text(self.TextFrame ....)
[16:52:03] <CWC> then i run it with 'F5'
[16:52:58] <CWC> then i can - app.gCodeWindow.insert('helllo',END)
[16:54:13] <CWC> when the app is run in emc, emc is waiting for a response.
[16:54:33] <CWC> so i dont think there is any way to debug at that point.
[16:55:02] <CWC> emc is waiting for the userland app to finish.
[16:56:00] <jepler> you can print debugging messages on sys.stderr; if you run emc from the terminal, they'll show up there
[16:57:06] <jepler> (though maybe not until you exit your program)
[16:57:46] <jepler> the Python code that calls the filter looks like this:
http://pastebin.ca/1511231
[16:58:17] <jepler> the differences between that and running at the terminal should be fairly modest: stdin and stderr are pipes instead of the terminal, and stdout is a file.
[16:58:49] <jepler> and there's an additional environment variable set
[17:00:15] <CWC> reading...
[17:01:55] <CWC> is that in the Axis source? i read through Axis and dont remember that method
[17:02:08] <CWC> guess it has to be
[17:03:02] <CWC> doesnt matter
[17:03:23] <jepler> If you use "idle -d" instead of "python" as the filter, it looks like it gives you the graphical idle environment, and you can hit F5 to start running
[17:03:40] <CWC> whoo hoo
[17:03:46] <CWC> never tried that
[17:03:58] <jepler> I didn't test that inside emc yet, just 'idle -d myscript.py' after reading the manual
[17:04:16] <CWC> ohh
[17:04:34] <CWC> trying...
[17:05:15] <CWC> slow under VNC
[17:05:29] <jepler> (huh, but then my program failed in a weird way under idle ..)
[17:05:54] <CWC> define weird
[17:07:07] <jepler> 'AttributeError: read' on an object that should be a file
[17:07:38] <jepler> oh, idle is diverting stdin and stdout to its window
[17:08:54] <CWC> i need to read the docs on the filter feature
[17:09:05] <CWC> have PROGRAM_EXTENSION
[17:09:17] <CWC> oh, nevermind
[17:09:21] <CWC> working...
[17:09:42] <jepler> hm, when I list multiple files on the commandline after -d, idle opens them all .. which is not what it should be doing
[17:11:56] <jepler> forget it, it doesn't work :(
[17:12:01] <jepler> bbl
[17:12:19] <CWC> gonna try anyway.
[17:19:33] <CWC> doesn't work
[17:20:26] <CWC> the app goes hangs when i "write to Axis"
[17:20:39] <CWC> er , the app hangs when i ...
[17:21:57] <CWC> the 'instance' would be in idle, not emc doing it that way anyway..
[17:25:21] <CWC> i can just use 'print'
[17:26:23] <CWC> thanks to all who tolerated...
[17:33:31] <CWC> anyone know if there a built in way to display 'Radius or Diameter Mode' in Axis for a lathe?
[17:34:01] <CWC> this is probably a pyvcp thing
[17:35:01] <CWC> i can see it in the mdi window
[17:35:06] <CWC> but..
[17:49:25] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[17:50:40] <Jymmm> wb
[17:51:53] <SWPadnos> hi
[17:52:18] <CWC> howdy
[17:53:47] <CWC> it looks like adding an indicator for radius/diameter mode in pyvcp would add it in another frame to the right of the backplot
[17:53:59] <CWC> eating screen
[17:55:46] <CWC> feature request?
[18:01:37] <geo01005> it sure would be nice is classicladder supported tags rather than these hard to remember variable names like 12
[18:01:48] <geo01005> "&B12"
[18:08:26] <CWC> havent looked at CL yet, it really cant do a 'string' tag???
[18:09:13] <CWC> is that a limitation of CL itself?
[18:09:29] <CWC> or the interface between emc
[18:09:30] <CWC> ?
[18:15:07] <cradek> CWC: HAL doesn't have strings, so I'm not sure what EMC/CL would do with them
[18:15:22] <cradek> CWC: also you're right, there is no radius/diameter indication in AXIS except the active gcode g7/g8
[18:16:12] <geo01005> cradek, it would just be useful to name variables in the interface, most PLC software I have seen does that.
[18:16:35] <cradek> yes, you can name variables
[18:17:06] <geo01005> how? I would sure like to know :)
[18:17:14] <cradek> you edit them in a table in the gui
[18:17:16] <SWPadnos> don't they show up as the name of the signal they're attached to?
[18:17:17] <CWC> got it.
[18:17:32] <cradek> SWPadnos: not anymore, but the signal shows up in the same table for reference
[18:17:37] <SWPadnos> ah, ok
[18:17:50] <SWPadnos> so, this looks cool:
http://www.newegg.com/Product/Product.aspx?Item=N82E16856101075&Tpk=shuttle D10
[18:17:59] <SWPadnos> too bad everyone says the touchscreen is crappy
[18:18:43] <geo01005> Awesome!! That greatly improves my day :)
[18:18:49] <cradek> hm, demo_sim_cl doesn't run anymore
[18:19:09] <bill2or3> Hmm, I need a htpc..
[18:19:30] <SWPadnos> that would be an awfully small and low-res screen ;)
[18:19:44] <SWPadnos> this one seems more popular:
http://www.newegg.com/Product/Product.aspx?Item=N82E16856101044
[18:19:55] <SWPadnos> there's a VFD behind the lower panel
[18:19:59] <SWPadnos> and it comes with a remote
[18:21:04] <SWPadnos> and they have an interesting USB feature - they call it "SpeedLink" - it basically lets you plug this and another computer together via USB, and this one shows up as a hard drive (or something)
[18:21:26] <cradek> http://timeguy.com/cradek-files/emc/symbols.png
[18:21:37] <skunkworks_> we have some shuttles on equipment here. They run too hot. you have to make sure you keep the heatsinks super clean.
[18:22:03] <bill2or3> we had the as workstations, the became to be called "Shittle"
[18:22:25] <skunkworks_> they have remote heatsinks that mount at the back of case.
[18:24:03] <CWC> wow, never noticed the htpc's before, those are cool
[18:24:23] <cradek> ^^ picture of the symbols/strings
[18:24:32] <tom2> tom2 is now known as tom3p
[18:26:44] <CWC> i see your point with tags on the classic ladder example page
[18:29:05] <CWC> could write an application to manage the data an spit out a Classsic Ladder config?
[18:29:24] <SWPadnos> like the CL editor? :)
[18:30:08] <CWC> oh?
[18:30:22] <CWC> problem is hal right?
[18:30:38] <CWC> debugging from hal?
[18:30:57] <cradek> what problem?
[18:31:25] <CWC> you have a tag in cl that maps to 1242939whatever in hal. i thought that was the problem
[18:31:51] <CWC> reading hal docs now...
[18:32:27] <CWC> i get it. sorry
[18:32:28] <cradek> sorry, I still don't understand
[18:33:42] <CWC> its the that hal doesnt support 'string literal' tags
[18:34:13] <CWC> i was stuck thinking the problem was in CL. sorry
[18:35:02] <CWC> even after you stated it was in the hal......
[18:35:05] <cradek> right, hal doesn't have a string type (although the name of every pin and signal is a string of course) - what would they do?
[18:39:25] <CWC> should i be looking in the hal configuration dialog to find modal g code states. i.e. G7/G8 rad/diameter
[18:39:50] <CWC> it looks like mostly system stuff
[18:42:01] <cradek> hal doesn't know anything about gcode - these are apples and oranges
[18:42:07] <CWC> i want to add a radius/diameter PyVCP indicator. not what emc component has the data. would that be the hal?
[18:42:19] <cradek> hal is hardware/interface abstraction
[18:42:44] <CWC> ok.
[18:43:02] <cradek> pyvcp displays and manipulates hal signals, so you cannot access internal gcode interpreter state there either
[18:43:11] <CWC> hmm.
[18:43:26] <cradek> I believe editing the gui of your choice is the only way to accomplish what you want
[18:43:40] <cradek> as you saw, that state is available as an "active gcode"
[18:44:16] <CWC> yeah, i had that feeling
[18:44:46] <CWC> i would want it to be on the backplot which is in OpenGL i think
[18:45:03] <CWC> which is a little over my head in python
[18:45:06] <cradek> yes it is
[18:45:11] <skunkworks_> heh
[18:45:13] <SWPadnos> I thought Les had made a patch to show DTG and position correctly
[18:45:25] <SWPadnos> (in dia vs rad mode)
[18:45:32] <CWC> dtg and position works
[18:45:39] <cradek> yes it all works fine
[18:45:45] <CWC> everything works, i love emc2
[18:46:29] <CWC> i just need a big sign that says i am in rad or dia mode
[18:46:33] <skunkworks_> cwc: what are you running with emc?
[18:47:08] <CWC> 9x20 lathe
[18:47:19] <skunkworks_> threading also?
[18:47:34] <CWC> not yet, building tooling
[18:47:44] <skunkworks_> newt
[18:47:44] <cradek> pick radius or diameter and never use the other :-)
[18:47:45] <skunkworks_> neat
[18:48:40] <CWC> @cradek - yeah, had that feeling too. i just dont think in radius mode
[18:49:05] <SWPadnos> then you should pick diameter mode ;)
[18:49:24] <cradek> SWPadnos: that seems like good advice
[18:49:33] <CWC> hahah. i use both.
[18:49:37] <SWPadnos> heh
[18:49:40] <CWC> is the problem...
[18:49:54] <SWPadnos> I would add G7 (or G8 or whichever it is) to RS274NGC_STARTUP_CODES
[18:50:12] <cradek> if you go down that road, you probably want in/mm on the display for consistency
[18:50:30] <cradek> "inch radius" "mm diameter" etc
[18:50:54] <CWC> rarely use metric, but good point
[18:51:24] <cradek> it's expected that you know your units when reading the position readout - I guess rad/dia is just another case of that.
[18:51:36] <cradek> they're just like another units difference
[18:52:42] <CWC> i completely agree.
[18:53:27] <CWC> but its bad if i forget/don't pay attention
[18:54:01] <cradek> well now I'm disagreeing with myself. both rad and dia are shown on the screen. the thing you want isn't information in the dro. it's part of internal interpreter state. it's much more like g90/g91 than readout units.
[18:54:21] <CWC> yep
[18:54:30] <cradek> this is a set of things that affect how the gcode you type is understood
[18:54:33] <CWC> its sugar
[18:54:47] <cradek> those things are reflected in the 'active gcodes' window already
[18:54:48] <CWC> correct
[18:54:54] <cradek> so now I think you don't need another readout
[18:55:10] <CWC> no i just go look at the mdi screen
[18:55:29] <CWC> usually i am there anyway
[18:55:35] <cradek> sure, the only time it matters one bit is when you're typing an mdi command
[18:55:45] <cradek> I know this because that's all g7/g8 affect
[18:55:50] <CWC> or the application i am writing in python
[18:56:05] <cradek> your application is broken if it does not specify g7/g8 and expects it to be one way or the other
[18:56:10] <CWC> but its canned in there too
[18:56:16] <cradek> it should also specify g20/g21 and g90/g91 etc etc
[18:56:21] <SWPadnos> it could probably be nice to see that active G-codes display when on the auto mode page
[18:56:30] <cradek> SWPadnos: why? it has no meaning
[18:56:45] <SWPadnos> sure it does - it lets you see the current state of the machine, like the backplot does
[18:56:56] <SWPadnos> unless it's "out of date"
[18:56:59] <cradek> no, it shows the state of the interpreter
[18:57:01] <SWPadnos> (due to readahead)
[18:57:20] <CWC> cradek is right imho
[18:57:28] <SWPadnos> when proofing code, the more you can see the better (IMO)
[18:57:50] <CWC> it doesnt fit emcs display standard
[18:58:01] <SWPadnos> which standard is that?
[18:58:05] <cradek> if you'd click a line in the preview or gcode display, and you'd get the interpreter state corresponding to that, I'd be all for it
[18:58:19] <cradek> but some random unrelated interpreter state does you no good
[18:58:22] <SWPadnos> that would be cool
[18:58:36] <SWPadnos> is it unrelated due to readahead?
[18:58:59] <SWPadnos> / queueing
[18:58:59] <cradek> yes the interpreter is always (?) ahead of execution
[18:59:01] <SWPadnos> ok
[18:59:09] <SWPadnos> in that case it wouldn't be too useful :)
[18:59:10] <cradek> except when in mdi mode
[18:59:18] <SWPadnos> sure
[18:59:18] <cradek> no, it's probably even confusing
[18:59:41] <SWPadnos> hmmm. interesting
[18:59:45] <CWC> i forgot about the readahead
[18:59:53] <cradek> sometimes I wish our architecture was different - wish I knew what it should be
[19:00:40] <SWPadnos> thinking back to the recent questions about effective program size limits, I wonder if isn't a big deal to do checkpointing (for reversal, or so you could keep track of interpreter state to show it when a line is clicked, etc.)
[19:01:24] <SWPadnos> since you can't have an infinitely sized program with any modern user interface, concerns about huge logs/checkpoint files may be immaterial
[19:01:41] <cradek> keep the interpreter state for each line interpreted?
[19:02:32] <SWPadnos> or just when it changes
[19:02:36] <cradek> I haven't done the math but it feels like it may be problematic
[19:03:12] <cradek> it changes at every line...
[19:03:29] <jepler> in a predecessor of AXIS I did pretty much that:
http://media.unpythonic.net/emergent-files/01227191152/rs274py-cone.png -- it never felt very useful, and the feature was dropped pretty early
[19:03:48] <SWPadnos> cool
[19:03:59] <SWPadnos> cradek, it doesn't necessarily change at every line
[19:04:20] <cradek> we're talking about different things then - I was thinking the entire state, which includes the position
[19:04:26] <SWPadnos> oh, sure
[19:04:31] <SWPadnos> I'm talking about modal codes
[19:04:32] <cradek> you mean the modes, I think
[19:04:35] <SWPadnos> yep
[19:05:04] <SWPadnos> and motion modes can be ignored (G0-3), since they're explicitly in the code already
[19:05:13] <SWPadnos> (actually they all are)
[19:05:19] <cradek> ?
[19:05:22] <SWPadnos> nevermind ;)
[19:05:25] <cradek> I forget what your goal was :-)
[19:05:32] <SWPadnos> err. me too
[19:05:36] <cradek> haha
[19:05:41] <cradek> then let's call it accomplished
[19:05:58] <SWPadnos> done
[19:06:13] <cradek> yay
[19:06:14] <SWPadnos> well, not done, but not important
[19:06:26] <SWPadnos> (not important enough to remember for 5 minutes anyway)
[19:09:36] <CWC> glad, you guys talked me out of that.. ;-)
[19:25:20] <Lerman_______> Lerman_______ is now known as Lerman
[20:07:21] <CWC> i figured out the python problem, it was throwing an exception that i was missing cause i did not run emc from the shell.
[20:08:11] <CWC> i recall Axis spawning a new window for exceptions, and got sucked in......
[20:08:33] <CWC> thanks again
[20:10:28] <SWPadnos> suckerrrr :)
[20:10:51] <SWPadnos> glad you found it. running from a terminal will often show you more information that from an icon
[20:12:31] <CWC> yeah, and i should know that. but it ran fine on every platform i tried until i ran it in emc
[20:13:32] <CWC> it would take a bunch of work to add the debuging i was looking for to Axis.
[20:14:21] <CWC> basically adding 'Idle' to Axis
[20:17:11] <CWC> i am better off just writing good code in the first place
[20:22:30] <geo01005> If only we could all write good code in the first place.
[20:24:25] <CWC> agreed. i recall seeing some 'interactive shell' code for another language. it was like 10 lines.
[20:26:30] <CWC> axis would need to spawn a new Toplevel and allow input/output from the interpreter
[20:27:36] <CWC> ill do some digging
[20:28:38] <SWPadnos> you may be able to change the .py handler to something like "idle blahblah.py" in your ini file
[20:28:44] <SWPadnos> but I don't know if it would work
[20:28:46] <SWPadnos> or help
[20:30:01] <CWC> jeppler and i tried. no workie. the 'instance' of the application would still be running in idle not axis
[20:30:22] <CWC> while:
[20:30:37] <SWPadnos> yes, it's an external program anyway
[20:30:49] <SWPadnos> not a pyvcp thing, but a g-code generator thing
[20:30:50] <CWC> echo -n "$prompt'
[20:30:58] <CWC> read line
[20:31:07] <CWC> eval "$line"
[20:31:10] <CWC> done
[20:31:25] <CWC> <end code>
[20:32:56] <CWC> that might do it
[20:33:07] <CWC> Courtesy of "UNIX F.A.Q.," 1993
[20:34:28] <CWC> its for debugging only, but it might help
[20:36:05] <CWC> and you could change things on the fly
[20:36:31] <geo01005> seb_kuzminsky: I'm working on a control project where I
[20:36:55] <geo01005> I'm not using EMC, just the hal and ClassicLadder with a 5i20 and some steppers.
[20:37:18] <seb_kuzminsky> geo01005: what's the project?
[20:37:22] <geo01005> Is there a way that I can reset (home) the stepgen position?
[20:37:31] <seb_kuzminsky> heh
[20:37:35] <geo01005> This is for my thesis.
[20:38:01] <geo01005> Think of it as developing a fuzzy logic controller for an sinker EDM.
[20:38:34] <geo01005> Or is it best to just use an offset and set the "home" position with that?
[20:38:40] <seb_kuzminsky> there's no way to do it just in the hm2 driver
[20:38:51] <geo01005> bummer...
[20:39:02] <SWPadnos> it would be a nice addition, I think
[20:39:26] <seb_kuzminsky> it'd be easy to do
[20:39:32] <SWPadnos> then stepper homing could work like encoder homing, since the "feedback" part would act like an encoder
[20:39:41] <seb_kuzminsky> the sw stepgen doesnt have it, and that's the interface i copied
[20:39:46] <seb_kuzminsky> but it could be added
[20:40:27] <geo01005> it isn't worth adding for this application.
[20:40:40] <SWPadnos> sure. it would be nice there too :)
[20:40:51] <seb_kuzminsky> i bet there's some trickery you can do in hal to get what you want
[20:40:54] <geo01005> * geo01005 thinks about how encoder homing works...
[20:41:01] <seb_kuzminsky> is there an offset component?
[20:41:13] <geo01005> I believe there is.
[20:41:22] <geo01005> I was just looking.
[20:42:00] <seb_kuzminsky> http://www.linuxcnc.org/docview/html//man/man9/offset.9.html
[20:42:00] <maddash> hi ho!
[20:42:10] <seb_kuzminsky> dont call me a ho!
[20:42:37] <maddash> er I meant it in the santa claus sense
[20:42:43] <geo01005> yeah, looks like the offset component will work.
[20:42:45] <seb_kuzminsky> oh well carry on then
[20:42:58] <maddash> has there been any previous attempts to port emc to arm?
[20:43:33] <maddash> I'd love to run emc on beagleboard
[20:43:46] <geo01005> most attempts have been from arm>hand>mouse>emc>machine ;)
[20:44:45] <SWPadnos> it has been tried, though not in real earnest, and hasn't worked
[20:44:48] <SWPadnos> on the beagleboard
[20:45:02] <maddash> oh, so there has been an attempt?
[20:45:04] <SWPadnos> a significant amount of effort was expended I think
[20:45:06] <SWPadnos> yes
[20:45:18] <SWPadnos> but it proved "too hard to be fun or interesting", I believe
[20:45:37] <maddash> is there anything documenting that attempt?
[20:45:50] <maddash> I'd love to give it a shot
[20:45:53] <SWPadnos> dunno
[20:46:14] <maddash> hm, maybe I should first try cross-compiling to arm
[20:46:27] <SWPadnos> RTAI proves to be a bitch
[20:46:56] <maddash> maybe we could bypass that
[20:47:03] <SWPadnos> -rt doesn't work so well
[20:47:19] <SWPadnos> (this is all from memory, so I could be wrong)
[20:47:39] <maddash> okey
[20:48:18] <seb_kuzminsky> -rt might work on hardware-assisted systems without a base thread, no?
[20:49:01] <SWPadnos> I think the max latency was in the 400-500 us range
[20:49:12] <seb_kuzminsky> yuck
[20:49:18] <SWPadnos> here's someone else who tried, and the 400 uS number pops up:
http://groups.google.com/group/beagleboard/browse_thread/thread/979703d56b67497c
[20:49:27] <maddash> I was planning on running the tp and possibly a ui on the beagleboard, with external stepgen
[20:49:45] <SWPadnos> that's what was tried - connected to a 7i43 via the GPIO connector
[20:52:26] <maddash> :(
[20:55:24] <jepler> emc-devel-2009-07-20.log:13:46 <jepler> fenn: Since rtai isn't ported to OMAP, I did some work based on rt-preempt and kernel threads. This gives some pretty good results on an x86 PC (enough to possibly run servo-thread-only systems) .. but on beagleboard I got 300us latencies in good trials and worse latencies in other trials..
[20:56:02] <jepler> (I seem to recall still seeing latencies of up to 4ms when accessing the sdhc)
[20:57:11] <jepler> anyway, it was around that time I got bored
[21:00:53] <seb_kuzminsky> yeah, 4ms is pretty boring
[21:02:54] <maddash> wtf
[21:03:19] <maddash> maybe we need to run closer to the hardware?
[21:03:31] <seb_kuzminsky> wt^G
[21:03:59] <maddash> the beagleboard's got a freakin' floating point co-processor
[21:04:58] <alex_joni> so did some 286's
[21:05:35] <SWPadnos> weren't they all external '287 chips?
[21:05:47] <maddash> cnc controllers shouldn't require multi-ghz
[21:05:47] <SWPadnos> (or Weitek)
[21:05:48] <alex_joni> sure
[21:05:57] <alex_joni> but still .. they had them ;)
[21:05:59] <SWPadnos> the beagle actually has it built in :)
[21:06:04] <alex_joni> if you could afford them
[21:06:08] <SWPadnos> (like the 486 started to do)
[21:06:10] <SWPadnos> yeah
[21:06:11] <alex_joni> SWPadnos: semantics :P
[21:06:27] <SWPadnos> Weitek WTL-4167 I think it was, but that may have been for the '386 family
[21:06:58] <SWPadnos> oh, I guess they did have chips for the 286 (and 68k even)
[21:07:25] <maddash> maybe I could write a tp from the ground up
[21:07:36] <SWPadnos> don't forget the RTOS
[21:07:48] <alex_joni> remember to do S-curve accel
[21:07:54] <SWPadnos> and jerk limiting
[21:08:11] <SWPadnos> for non-trivial kinematics machines too, while you're at it :)
[21:08:26] <maddash> s-curve accel? as in linear jerk?
[21:08:30] <alex_joni> yeah
[21:08:35] <maddash> why?
[21:08:41] <SWPadnos> because it's better
[21:08:56] <maddash> I meant, what's that much better about linear jerk, vs. linear accel?
[21:08:58] <alex_joni> because you can :P
[21:09:12] <alex_joni> what's better about linear accel vs. linear speed ?
[21:10:22] <skunkworks_> might as well just use this
http://www.safeguardrobotics.com/default.aspx?tab=cncbrain
[21:10:35] <skunkworks_> ;)
[21:10:43] <archivist> heh that thing
[21:10:48] <seb_kuzminsky> ooh, it's "literally a brain"
[21:11:06] <archivist> have they sold any yet
[21:11:15] <alex_joni> or this:
http://www.talkshopbot.com/forum/messages/2/19159.jpg
[21:11:16] <skunkworks_> I think it is still vaporhardware
[21:12:38] <alex_joni> it also has "massively-parallel processing framework"
[21:13:20] <bill2or3> like a brain-cluster?
[21:13:30] <bill2or3> a rack, of vats, of brains?
[21:13:49] <archivist> couple of PIC chips probably
[21:13:54] <skunkworks_> http://www.cnczone.com/forums/showthread.php?t=72401
[21:14:03] <alex_joni> oh cool..
[21:14:05] <geo01005> fpga right? (brain)
[21:14:05] <alex_joni> "If the machine enters a fault state during machining, the CNC Brain will automatically calculate the course of corrective action. "
[21:15:02] <skunkworks_> why can't emc do that? ;)
[21:15:08] <skunkworks_> and double closed loop?
[21:15:37] <alex_joni> :P
[21:15:38] <SWPadnos> double closed loop == infinity symbol
[21:15:53] <alex_joni> or the simbol for a toilet in some countries
[21:15:57] <SWPadnos> heh
[21:16:11] <alex_joni> well.. emc certainly doesn't do this:
[21:16:12] <alex_joni> MPP (Massively Parallel Processing) framework - Interconnection matrix for high-complexity data processing and interdependent interaction.
[21:16:27] <SWPadnos> I prefer independent interaction
[21:16:31] <archivist> I did a double loop in and audio amp..soon learnt infinity
[21:16:39] <alex_joni> I prefer independent noninteraction
[21:16:53] <alex_joni> archivist: chuck norris counted to infinity.. twice
[21:17:00] <archivist> hehe
[21:17:53] <alex_joni> that MPP is probably on the bottom board:
http://www.safeguardrobotics.com/gallery/cncbrain/e_stack.jpg
[21:18:24] <bill2or3> Massive!
[21:21:10] <alex_joni> cradek: another cool clock (actually calendar) idea:
http://blog.makezine.com/archive/2009/07/capillary_action_colors_calendar_in.html?CMP=OTC-0D6B48984890
[21:23:55] <archivist> if drying and clogging dont win
[21:24:21] <skinnypup> just thinking i'd friggin spill something on that
[21:35:08] <alex_joni> good night all
[21:35:21] <seb_kuzminsky> seeya alelx
[21:50:45] <geo01005> have there been any alternative hal/schematic solutions other than eagle2hal?
[23:11:29] <geo01005> seb_kuzminsky: does the acceleration-velocity limiting work on the hm2 stepgen?
[23:11:44] <seb_kuzminsky> yes
[23:12:07] <geo01005> hmm, I must be missing something in my configuration.
[23:12:23] <seb_kuzminsky> you're on 2.3.2 or newer, or trunk?
[23:12:32] <geo01005> yeah 2.3.2
[23:12:52] <geo01005> the limiting isn't really the problem, but there are no steps being generated.
[23:13:00] <seb_kuzminsky> oh well that's different ;-)
[23:13:03] <seb_kuzminsky> is .enable on?
[23:13:05] <geo01005> stepgen in enabled
[23:13:07] <seb_kuzminsky> heh
[23:13:14] <seb_kuzminsky> "is it plugged in?" :-P
[23:13:30] <geo01005> hm2 read, write, and watchdog are all on the base thread.
[23:13:36] <geo01005> The base thread is running.
[23:13:40] <seb_kuzminsky> how fast?
[23:13:44] <geo01005> 1ms
[23:13:46] <seb_kuzminsky> ok
[23:14:00] <seb_kuzminsky> stepgen.scale?
[23:14:13] <geo01005> I think I have it set to .000625
[23:14:25] <seb_kuzminsky> shouldnt it be the reciprocal of that?
[23:14:31] <seb_kuzminsky> it's "steps per user-unit"
[23:14:45] <geo01005> Ahhh :)
[23:15:17] <seb_kuzminsky> yay, an easy bug :-)
[23:15:19] <seb_kuzminsky> bbl dinner
[23:15:57] <geo01005> Thanks :)
[23:16:02] <geo01005> works now.
[23:16:23] <seb_kuzminsky> great :-)
[23:16:25] <seb_kuzminsky> seeya
