#emc | Logs for 2008-10-21

Back
[01:11:16] <fenn_> fenn_ is now known as fenn
[03:33:33] <user__> user__ is now known as SkinnYPuPP
[07:52:01] <archivist> logger_emc: bookmark
[07:52:01] <archivist> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2008-10-21.txt
[07:52:28] <fragalot> picky lil' bot :o
[08:30:13] <cncman> hi
[08:31:43] <archivist> hi
[08:34:50] <fragalot> hi
[09:25:56] <Vq^> hi
[10:06:16] <micges> good morning
[11:02:41] <piasdom> g'mornin all
[11:13:54] <Dallur> morning
[12:15:07] <piasdom> how can i backup my system and drivers ?
[13:32:56] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:29:56] <skunkworks> http://voodoocnc.com/
[14:30:11] <skunkworks> http://www.cnczone.com/forums/showthread.php?t=18861&page=11
[14:34:38] <cncman> hi, anybody has login access to the opencores.org web?
[14:34:46] <SWPadnos> yep
[14:39:38] <jepler> cncman: you need some file from there?
[14:39:46] <cncman> ye
[14:39:50] <cncman> yes jepler
[14:39:57] <cncman> swpadnos is helping me
[14:40:00] <jepler> ok
[14:40:00] <cncman> thx
[14:49:44] <archivist> went to talk by mach3 guys in UK, interesting what the can and canot do
[14:49:58] <archivist> the=they
[14:51:04] <jepler> oh yeah?
[14:51:06] <SWPadnos> can=custom screens and reasonably easy extensions with VB-like stuff
[14:51:11] <SWPadnos> can't=feedback :)
[14:51:15] <archivist> :)
[14:51:52] <archivist> seems its under new ownership
[14:53:00] <SWPadnos> yep - Brian is it?
[14:53:22] <archivist> yes he gave talk on cutting speeds/feeds that I went to
[14:54:02] <jepler> interesting: http://freemodbus.berlios.de/index.php
[14:54:12] <SWPadnos> yep - seen that
[14:54:13] <skunkworks> I have only met the retired art. Was brian at the cncfest?
[14:54:18] <SWPadnos> ys
[14:54:20] <SWPadnos> yes
[14:54:31] <skunkworks> huh - I missed him then.
[14:54:32] <jepler> (bsd license modbus implementation, includes ports to various micros)
[14:54:56] <SWPadnos> yeah - that's a target library, right?
[14:55:27] <jepler> SWPadnos: not sure if it's target only
[14:57:27] <SWPadnos> ah ok - they have a master module as well (in CVS)
[14:59:15] <SWPadnos> modbus is actually pretty trivial to implement - it's all the junk around serial port error checking that's a PITA
[15:01:37] <archivist> saw a guy demoing his cam software and snap his endmill :)
[15:01:47] <SWPadnos> oopsie
[15:01:48] <fragalot> lol?
[15:01:58] <archivist> :)
[15:02:00] <fragalot> somehow that reminds me of bill gates
[15:02:00] <SWPadnos> it's only fun until someone loses an eye
[15:02:15] <fragalot> SWPadnos: or a nut
[15:02:24] <SWPadnos> well, I suppose
[15:02:27] <archivist> it stayed stuck in the ally he went too deep in
[15:02:50] <SWPadnos> thus proving that software lets you make mistakes much more quickly and efficiently
[15:03:17] <fragalot> :D
[15:03:52] <archivist> cut air first :)
[15:05:05] <fragalot> archivist: air isn't free you know...
[15:06:44] <SWPadnos> cool: http://www.opencores.org/projects.cgi/web/opencores/tmp_news4
[15:07:04] <archivist> some of the chinese mills and lathes seem acceptable quality these days
[15:07:16] <SWPadnos> don't assume that China can't make good stuff
[15:07:38] <SWPadnos> they have a lower minimum quality, but very nearly the same high quality limit as elsewhere
[15:07:55] <fragalot> I quite like the taiwanese ones at work
[15:08:15] <fragalot> mighty fine machines in terms of maintenance too
[15:08:58] <archivist> there is still some crap being imported specially rotary and xy tables
[15:09:03] <SWPadnos> man - 4GB of RAM, $45
[15:09:10] <fragalot> SWPadnos: :o bargain
[15:09:17] <SWPadnos> yeah
[15:09:39] <SWPadnos> it's not the fastest available, DDR2/800 at 5-5-5-18
[15:09:51] <SWPadnos> Corsair thogh
[15:10:12] <fragalot> 800 is plenty
[15:10:31] <SWPadnos> yes
[15:11:31] <jepler> I've totally lost track of the meaning of RAM specs
[15:11:38] <SWPadnos> heh
[15:11:52] <SWPadnos> you should see the list of timings you can adjust on the ASUS Rampage Extreme motherboard
[15:12:02] <SWPadnos> there are about 30-40 of them
[15:12:48] <jepler> they should just put a checkbox: [ ] Gain 5% performance and lose 100% reliability
[15:13:08] <SWPadnos> heh
[15:13:14] <SWPadnos> they have that too ;)
[15:13:15] <archivist> bleh whats wrong with old fashioned delay lines to get timing
[15:13:26] <SWPadnos> there's a separate "step up" setting
[15:13:39] <SWPadnos> you can do normal, faster, extreme, and crazy
[15:13:55] <fragalot> lol
[15:13:56] <SWPadnos> or something like that, but I know that "Crazy" is one of the options
[15:14:06] <fragalot> SWPadnos: how about "Crazy" with 1200Mhz ECC ram?
[15:14:17] <SWPadnos> ECC, hmmm
[15:14:28] <fragalot> :)
[15:14:29] <SWPadnos> I'll bet you need JEDEC settings for that
[15:14:34] <SWPadnos> ie, not all that fast
[15:15:02] <fragalot> :D
[15:19:42] <jepler> hm, this so-called modbus spec (MODBUS Application Protocol Specification V1.1b) doesn't define what the CRC algorithm/polynomial is
[15:22:24] <SWPadnos> 1021 I bet. there are tables in the source
[15:22:40] <SWPadnos> r is that 1042? hmmm
[15:22:44] <SWPadnos> err, 1041
[15:23:28] <jepler> it's described in "Modicon Modbus Prococol Reference Guide PI-MBUS-300 Rev. J" but there's a big note that says it's an obsolete specifcication, not to be used for new implementations
[15:24:16] <SWPadnos> ah, 1021
[15:24:23] <SWPadnos> heh
[15:24:29] <jepler> oh I guess I should be reading "Modbus Serial Line Protocol and Implementation Guide V1.02" for this information.
[15:24:38] <SWPadnos> that seems likely
[15:25:07] <jepler> why'd they put the obsolete doc above the current doc on their page? duh
[15:25:11] <SWPadnos> I think it's the CCITT polynomial (on wikipedia)
[15:25:46] <SWPadnos> I wonder if that's the most recent version of the Modicon-specific protocol, before it was released as an open-ish standard??
[15:30:42] <jepler> huh -- a delay of more than 1.5 character times during a message is an error condition in modbus. I see what you mean about error handling being the difficult part of this standard
[15:31:10] <SWPadnos> it's almost always that way with serial ports, in my experience
[15:31:33] <jepler> (haha, wtf, at the bottom of that page they have a "remark" that you should actually ignore that requirement and use a different requirement instead)
[15:32:05] <SWPadnos> they're unreliable, and it's har d to decide how long is too long (considering that a valid 300-baud byte takes an eternity in CPU cycles)
[15:32:09] <SWPadnos> heh
[15:35:20] <archivist> if the cpu sucks the data fast enough AND there is no noise on the line AND the handshake works as advertised, serial should never lose data
[15:35:46] <jepler> hm and you don't know the packet length up front, so you have to do something like rely on dead time on the serial line to determine a packet is complete
[15:35:47] <archivist> takes me back a few years
[15:35:52] <SWPadnos> you're right. it shouldn't lose data
[15:36:21] <SWPadnos> you know the packet length once you've received the number of elements field (I think)
[15:36:36] <jepler> (you can know it by looking at the early bytes of the ADU if it's been reliably received, but you don't know that until you've received the end of the PDU and checked the CRC)
[15:36:44] <SWPadnos> right
[15:46:36] <jepler> Either their explanation of the "CRC" algorithm is wrong, or they're describing a nonstandard variant of CRC
[15:46:47] <jepler> too bad they give no test vectors
[15:47:16] <jepler> they say that "(if the LSB was 0): Repeat step 3 (another shift). (if the LSB was 1): Exclusive OR the CRC register with the polynomial value"
[15:48:18] <jepler> (sounds like for a 0 bit you shift twice or until you get a non-0 bit or something)
[16:14:09] <HAL9000> HAL9000 is now known as SkinnYPupP
[17:35:57] <SWPadnos> heh: http://www.youtube.com/watch?v=_K-Z0N-PhM4
[19:45:54] <maddash> oh, if I had a camcorder, I'd show you the beauty of my PWM LED
[19:47:31] <SWPadnos> thanks, but I have dimmer switches
[19:47:37] <SWPadnos> so I've seen it before
[19:48:08] <archivist> I did RGB pwm leds for a job
[19:48:22] <archivist> * archivist has PIC coded it
[19:48:49] <maddash> archivist: which model?
[19:49:18] <archivist> 18f628 iirc
[19:49:31] <maddash> oh, *that* one.
[19:49:46] <maddash> I could fall asleep watching this thing
[19:50:24] <SWPadnos> heh
[19:50:51] <SWPadnos> I guess now wouldn't be the time to mention the 16-channel PWM LED controller I designed/programmed, for theater effects ... :)
[19:51:00] <maddash> if the boss catches me sleeping on the job, I could blame it on the project
[19:51:00] <archivist> :)
[19:51:18] <maddash> SWPadnos: ahhhhhhhh. *yawn*
[19:51:23] <SWPadnos> using an AVR and software PWM
[19:51:54] <maddash> 16-channels? meaning 16 different, independent PWM outputs?
[19:51:56] <SWPadnos> with programmable sets of transitions, blinking, marquees, etc, clocked by external triggers
[19:51:59] <SWPadnos> yes
[19:52:01] <jepler> oh yeah, I have a vague recollection that you had a clever trick for the software pwm
[19:52:06] <SWPadnos> using software PWM
[19:52:14] <SWPadnos> yep, vaguely clever, that's me :)
[19:52:29] <maddash> using a timer, though, right?
[19:52:44] <SWPadnos> compare and shift - the compare puts the result of the comparison in the carry, so you end up with a byte to output directly
[19:52:48] <SWPadnos> no, no timer
[19:52:53] <archivist> who needs timers
[19:53:04] <maddash> then how do you delay?
[19:53:10] <maddash> tight loop?
[19:53:10] <jepler> maddash: there aren't 16 compare registers in any avr
[19:53:13] <SWPadnos> it did a couple of kHz PWM, with 8-bit resolution
[19:53:39] <jepler> what, you didn't do pdm?
[19:53:48] <SWPadnos> nope
[19:53:54] <jepler> putz
[19:54:01] <jepler> all the cool kids do pdm now
[19:54:01] <SWPadnos> one counter for PWM, one each for PDM
[19:54:11] <maddash> jepler: whaat?
[19:54:47] <SWPadnos> also, using PWM made sure that the LEDs are all off during the end-of-loop processing (reloading counts, checking inputs, doing fades, etc)
[19:55:13] <SWPadnos> this was capable of running 2-4A per channel, at voltages up to 36V
[19:55:33] <SWPadnos> and we used 4 of these boards on one show
[19:55:39] <SWPadnos> or was it 5?
[19:55:54] <maddash> meh. bbrb, pharmacy.
[20:00:27] <skunkworks> hmm - http://imagebin.ca/view/vUIHJyy.html
[20:00:40] <skunkworks> That is .1v per div
[20:00:45] <SWPadnos> spiky
[20:00:52] <skunkworks> voltage across the sense resistor
[20:00:54] <SWPadnos> is that probe ringing or real?
[20:01:10] <skunkworks> hmm
[20:01:17] <skunkworks> * skunkworks should calibrat it..
[20:01:37] <SWPadnos> you're not going to get spikes that big from ring alone, but it could be a part of it
[20:02:11] <SWPadnos> what's the horizontal scale, and the scope bandwidth?
[20:02:18] <skunkworks> well - it looks fine from the scope square wave.
[20:03:15] <SWPadnos> is that a 0.01-ohm sense resistor? (so roughly 10A)
[20:03:55] <skunkworks> yes - .015
[20:04:03] <SWPadnos> ok, 7A
[20:04:15] <SWPadnos> and the timebase of the trace?
[20:04:22] <skunkworks> hold on
[20:05:06] <skunkworks> 2us
[20:05:09] <archivist> * archivist would expand the ringing to see frequency
[20:08:38] <alex_joni> g'night all
[20:09:20] <skunkworks> http://imagebin.ca/view/PGrgFY.html
[20:09:53] <skunkworks> .1us
[20:11:01] <SWPadnos> 70kHz?
[20:11:15] <SWPadnos> seems fast-ish to me, but I'm no expert
[20:11:28] <SWPadnos> (the first trace that is)
[20:12:00] <SWPadnos> scope bandwidth?
[20:12:26] <skunkworks> crap
[20:12:31] <SWPadnos> 60MHz?
[20:12:41] <skunkworks> Someone was playing with the scope. The first trace should be 20khz
[20:13:05] <skunkworks> the calibrate knob was turned all the way
[20:13:11] <SWPadnos> heh -oops
[20:13:15] <skunkworks> yeh
[20:13:30] <skunkworks> so - the 70kh should be 20khz. I just measured it.
[20:13:50] <skunkworks> which is what the pluto puts out.
[20:14:13] <skunkworks> 60mhz scope
[20:15:55] <SWPadnos> ok, that's the frequency of the ringing you're getting
[20:15:56] <skunkworks> wow - the ring is at around 20mhz?
[20:16:14] <SWPadnos> uh - oh, so the second image had CAL problems too?
[20:16:18] <skunkworks> yes
[20:16:20] <skunkworks> sorry
[20:16:38] <SWPadnos> np
[20:18:07] <SWPadnos> it's bad to start typing when your mail reader has focus
[20:18:35] <skunkworks> http://imagebin.ca/view/6U3eikh.html
[20:19:11] <skunkworks> .2us
[20:19:51] <archivist> interesting secondary ring 3 divs in
[20:20:11] <archivist> cable effects probably
[20:22:15] <Hugomatic> Hi guys... I'd love to get some help with my lathe config... it stopped working: Axis works, but my parport does not seem to get any signal. The config for my milling (not generated by stepconf) is still working as before. Any idea on how to troubleshoot this?
[20:24:03] <jepler> the lathe config was working but then it stopped?
[20:24:28] <archivist> hardware fail on the lathe?
[20:24:57] <Hugomatic> It was working when I first made it with stepconf wizard. Now I can't even make the motors work from stepconf wizard
[20:25:26] <Hugomatic> Hardware is ok, I can use it with my milling config
[20:26:14] <jepler> what did you change or update since it last worked?
[20:26:42] <Hugomatic> I can't think of anything beside the ubuntu updates
[20:30:04] <jepler> the file /var/log/dpkg.log shows what packages were changed on what dates. If you find a linux-image, rtai-modules, or emc2 package update since the last time you know your configuration worked, then it could be due to that.
[20:31:24] <jepler> then you can experimentally downgrade the package to the old version and see whether that changes the behavior. Example:: sudo apt-get install emc2=1:2.2.5
[20:31:41] <jepler> (later, to go back to "the latest version", "sudo apt-get install emc2")
[20:32:16] <Hugomatic> Ok...
[20:32:54] <jepler> if you establish that a particular version of a particular package works, but another doesn't, then that helps us figure out what problem we introduced.
[20:34:31] <jepler> (only go down this route if you're really certain that nothing about your hardware or your configuration files has changed, since it's a bit time consuming -- you should probably reboot each time you want to try with a different package version, just to make sure nothing is hanging around. for sure after changing linux-image-rtai)
[20:41:11] <cradek> are you positive this is the pattern you are seeing? I've had a problem where the first run of EMC after a reboot would drive the parallel port, and subsequent ones would not
[20:41:21] <maddash> * maddash checks for signs of "software pwm" in the logs
[20:42:39] <maddash> ramp gen is to A/D as PWM+low-pass filter is to D/A?
[20:42:51] <Hugomatic> You are right about the time consumption... the dpkg log files are huge, and there is no change in the emc package during that time. I suspect the rtai update is to blame, but I still have a config that works (for my mill). I can restart emc without problems
[20:44:08] <Hugomatic> How can I know my parport adress?
[20:44:25] <maddash> dmesg|grep parport
[20:44:33] <maddash> er
[20:44:34] <cradek> it's extremely unlikely that rtai cares whether emc is running a mill or lathe configuration. I really suspect changing pacakges is the wrong approach to troubleshooting this
[20:45:03] <maddash> as root: 'modprobe parport_pc && dmesg|grep -i parport ; modprobe -r parport_pc'
[20:46:09] <Hugomatic> maddash: both commands give me empty results
[20:47:41] <maddash> :(
[20:48:10] <skunkworks> lspci -v
[20:48:20] <maddash> no, no
[20:48:45] <maddash> isn't there a probe_parport hal module somewhere?
[20:49:27] <cradek> yes
[20:50:20] <maddash> Hugomatic: when you load the parport_pc module, you should see some messages in "dmesg|tail"
[20:50:52] <Hugomatic> maddash: how do I load the parport_pc module?
[20:51:06] <maddash> sudo modprobe parport_pc
[20:51:27] <cradek> that won't work if parport_pc is blacklisted (like it should be)
[20:51:50] <cradek> you can insmod the file directly though
[20:52:12] <Hugomatic> dmesg tells me I have ppdev, and that "sysfs: duplicate filename 'parport_pc' can not be created"
[20:52:18] <maddash> meh why would it be blacklisted?
[20:52:42] <maddash> Hugomatic: find /lib/ -iname "*parport*"
[20:53:02] <cradek> maddash: because it interferes with emc
[20:53:41] <maddash> cradek: right, but were you trying to say that the emc installation autoblacklists parport_pc? because that's not very nice
[20:53:44] <Hugomatic> I get 5 files listed in: /lib/modules/2.6.24-16-rtai/kernel/drivers/parport
[20:53:57] <cradek> yes it does
[20:54:02] <maddash> boo
[20:54:09] <maddash> that's bad
[20:54:15] <cradek> sez you
[20:54:54] <maddash> what if I have two different kernels, A and B, where booting into A is for emc, and booting into B is for parport_pc fun?
[20:56:43] <cradek> then you'll have to do something about it - but we have not yet run into someone who unplugs their mill, reboots, and plugs in a printer, then reboots and plugs the mill back in. this is exactly what 99.9% of emc users want to happen (i.e. emc/parport works)
[20:56:44] <SWPadnos> then you need to reboot every time you change what you're doing
[20:58:38] <maddash> it's very presumptous of emc to start touching my /etc/modprobe.d/ files without my consent
[20:58:48] <Hugomatic> Both my configs (the working mill one and the broken stepconf one) have "loadrt hal_parport cfg=0x378" in the hal files so this is not the problem.
[21:04:15] <Hugomatic> The Emc HAL scope and the HAL configuration both show me that the pins are 'live', but the mototrs don't move
[21:05:28] <cradek> sure the lathe setup is not just misconfigured? lathe needs some enable signal maybe?
[21:07:15] <Hugomatic> I don't think so, because AXIS moves the tool as if everything was OK.
[21:08:05] <cradek> I mean the lathe hardware
[21:08:39] <Hugomatic> cradek: its a Sherline lathe, its very simple
[21:09:29] <cradek> how have you determined the hardware is working? is it the same driver, power supply, etc, you use with the mill?
[21:09:45] <cradek> I'm trying to understand what troubleshooting you have done so far
[21:10:38] <Hugomatic> I can run the mill config connected to the lathe motors,
[21:14:44] <SWPadnos> Hugomatic, check the port setup and make sure the lathe settings match the mill config settings
[21:15:30] <SWPadnos> ort are you saying that the computer with the mill setup also turns the lathe motors, but a different PC with the lathe setup doesnt?
[21:16:40] <jepler> "<Hugomatic> Hi guys... I'd love to get some help with my lathe config... it stopped working" -- from this I thought I understood that at one point the lathe configuration worked. but it sounds less like that was ever the case.
[21:18:07] <cradek> bbl.
[21:20:00] <Hugomatic> jepler: I have to admit you are right. I have found that my config is not working when I select "Sherline" as the driver type in stepconf, so I may have edited it without checking it, and only found the problem today.
[21:21:00] <SWPadnos> that option only sets the step timing or the step/dir arrangement. it does nothing else related to a Sherline machine
[21:21:09] <jepler> it's come to my attention recently that (A) the sherline timings in stepconf are not right and (B) nobody can actually tell me what the right sherline timings are and (C) they may require such long "step length" timings that stepconf will never write a correct configuration file.
[21:21:33] <jepler> ooh quittin' time
[21:43:05] <Paragon> hello all...
[21:43:45] <Paragon> Just been playing around with polymorph plastic. Awsome stuff :-)
[22:08:50] <archivist> hmm not seen that before Paragon looks nice to test a casting method out
[22:09:48] <fenn> that's the stuff reprap uses
[22:11:00] <Paragon> Thats right fenn I saw it on the link you showed us http://reprap.org/bin/view/Main/AssemblingDarwinMachinery#Z_belt I have made one of the the timing belt pulles in the method explained.
[22:11:17] <archivist> Im more used to lead casting
[22:11:37] <fenn> Paragon: did it work?
[22:12:12] <Paragon> I made the mold out of it too. it machined well but one need to take it slow due to it's low melting point.
[22:12:45] <fenn> heh then just throw your chips into a pot of water right?
[22:13:00] <Paragon> The timing belt fits well but i have not tried it in the field as yet
[22:13:29] <Paragon> Thats right and re-use
[22:13:47] <fenn> where did you get it btw?
[22:14:08] <Paragon> I am think of making a motor mount out of it and maybe motor coupling too.
[22:14:25] <Paragon> one sec I find the link...
[22:15:54] <archivist> I found Maplin sells it over here
[22:16:35] <Paragon> Very expensinve in Mapplin! I bought 2kg from http://www.tomps.com/shop/advanced_search_result.php?keywords=polymorph&x=0&y=0
[22:16:59] <Paragon> Ebay has it listed too.
[22:17:33] <Paragon> £12.86 per KG + vat + delivery
[22:17:33] <dmess> ren-shape might be ok for a couple shot low pressure mold ours
[22:18:20] <Paragon> I am trying to find a moldable plastic that melts say around 100C but no luck yet
[22:19:09] <Paragon> dmess: thats a resin right?
[22:20:24] <dmess> we used to get cubes... its like micro-bubbles and resin
[22:21:07] <Paragon> Just found it on google. its made by huntman
[22:21:14] <dmess> cuts well.. lasts in h2o for a while.. we used them as prototype pulp moulds
[22:21:28] <dmess> sount right
[22:21:36] <Paragon> ok
[22:22:09] <Paragon> One thing I will say the polymorph when hardened is very tough indeed
[22:23:02] <dmess> ive never heard of it
[22:23:03] <archivist> I wonder how long it lasts, as some plastics die with age
[22:23:27] <dmess> all die with sunlight..
[22:24:46] <Paragon> Not sure how long it last but I think quite a while. But it's good for proto work. I read somewhere it has over 500 mpa. that will probably mean more to guys then me. ;-)
[22:26:14] <Paragon> It's Biodegradable in soil too.
[22:26:49] <Paragon> Tensile Strength: 580 kg/cm² Is that strong?
[22:27:16] <roberth> 7075-T6 alli is around 506MPA give u an idea
[22:27:59] <Paragon> roberth: I think I got the mpa wrong ;-) I meant 580 kg/cm²
[22:28:32] <roberth> Paragon, this site is pritty nice for material spec and conversions, http://www.matweb.com
[22:28:48] <Paragon> taking a look now...
[22:28:55] <roberth> search the material name and i will give u a list, nice for them materials ur not sure on
[22:32:58] <Paragon> From the search on it showed multiple listing for Polycaprolactone but I think the mpa is around 65 ish
[22:34:26] <Paragon> http://en.wikipedia.org/wiki/Polycaprolactone
[22:34:43] <roberth> yea its not a lot on conversion into mpa depends on its other properties
[22:36:34] <Paragon> It can even be used as a biomaterial in medical implantable applications ... look out james bond ;-)
[22:47:51] <Paragon> Check out this stuff ... http://en.wikipedia.org/wiki/Plastarch_material