Back
[06:41:08] <skunkworks> http://bbs.homeshopmachinist.net/threads/68162-Tormach-have-announced-the-PCNC440-new-mill?p=1005058#post1005058
[07:00:51] <malcom2073> I feel like every time I read a post with someone bashing on LinuxCNC, the last time they tried it was 7-8 years ago.
[07:10:38] <skunkworks> yep
[07:10:56] <skunkworks> sparky helped out
[07:39:00] <Tom_itx> you guys are on acid??
[07:39:24] <skunkworks> I don't think so...
[07:44:20] <Tom_itx> acid is so... 60's anyway
[07:44:57] <Tom_itx> seems he is way behind on all fronts
[08:00:59] <rob_h> you should tell them that Brother CNC use Linux operating system and thats one quick powerfull machine they make and many operators love it
[08:25:23] <skunkworks> My goal is to do "perfect" threads, and I am pretty much getting there with now the CSMIO.
[08:25:23] <skunkworks> Hope to migrate to mach4, Real Soon Now.
[08:25:23] <skunkworks> Ive spent over 2000 hours on the threading stuff, over 13 years since 2002 or so.
[08:41:56] <jepler> > Debian had eight hundred thousand bugs reported in its history.
[08:42:44] <malcom2073> They should learn to write less buggy software
[08:46:41] <skunkworks> http://dilbert.com/strip/1995-11-13
[08:49:39] <jepler> I knew the word "minivan" would appear
[08:54:38] <malcom2073> haha awesome
[09:31:14] <pcw_home> Anyone have an idea of what gone wrong here? (forum question)
[09:31:15] <pcw_home> Traceback (most recent call last):
[09:31:17] <pcw_home> File "/usr/bin/axis", line 58, in <module>
[09:31:18] <pcw_home> import gcode
[09:31:20] <pcw_home> ImportError: /usr/lib/librs274.so.0: undefined symbol: _Z10CLAMP_AXISi
[09:46:44] <cradek> what caused it?
[09:50:05] <seb_kuzminsky> pcw_home: link?
[09:50:51] <pcw_home> http://www.linuxcnc.org/index.php/english/forum/9-installing-linuxcnc/29682-upgrade-25-to-26-and-to-27nothing-works
[09:53:46] <seb_kuzminsky> thanks
[09:53:50] <pcw_home> sort of sounds like the upgrade was botched somehow
[09:55:21] <cradek> yeah but how?
[09:55:28] <cradek> also ImportError: /usr/lib/python2.6/dist-packages/linuxcnc.so: undefined symbol: _ZN3NML5writeER6NMLmsg
[09:56:06] <cradek> I was going to guess it was an incorrectly (incompletely) built RIP, but it doesn't look like that
[09:56:51] <cradek> what is athlon64? this looks like our normal lucid i386 kernel
[09:57:13] <seb_kuzminsky> that's the old amd 64-bit machine
[09:57:24] <seb_kuzminsky> it should have working 32-bit, which is what he's running, based on his kernel
[09:57:31] <cradek> oh he's just saying what kind of cpu his machine has
[09:59:09] <seb_kuzminsky> i'm going to ask him for "dpkg -l 'linuxcnc*'" and "dpkg --audit", anything else on the first go-round?
[10:00:33] <cradek> does --audit show you whether the files still match the package?
[10:00:49] <jepler> athlon64 is a marketing name for amd's early 64 bit capable CPUs
[10:01:24] <seb_kuzminsky> cradek: no, it just tells you if the packages are installed correctly, or if they're half-installed
[10:01:39] <seb_kuzminsky> the one that verifies the files is debsums
[10:02:05] <cradek> it would be nice to verify
[10:02:17] <cradek> he might have half of a make-install or something here
[10:02:41] <cradek> and maybe ask him to describe how he did the update
[10:02:47] <seb_kuzminsky> yeah
[10:05:19] <seb_kuzminsky> ok, i dun axed him
[10:05:22] <seb_kuzminsky> thanks for the pointer, pcw_home
[10:05:39] <seb_kuzminsky> the partial make install is a good idea
[10:07:20] <cradek> I've not yet personally seen the 2.7 package run on lucid, but I sure know 2.6 worked
[10:09:20] <seb_kuzminsky> hm, the Download page on wlo doesn't mention the 2.7 install image
[10:43:33] <cradek> > After dragging the votive candle holder cutting patterns over the image of the two sheets of material, Dan hit the send button on the iPad. The data was sent via Wi-Fi to the cloud and then to the Glowforge machine.
[10:43:56] <cradek> [a cnc laser cutter]
[11:03:10] <seb_kuzminsky> glowforge
[11:03:14] <seb_kuzminsky> that thing looks neat
[11:09:18] <seb_kuzminsky> i just installed lucid/rtai/2.5 off our 2.5 ISO, upgraded to 2.6 using the instructions on the wiki, and ran sim/axis/axis without trouble
[11:13:46] <seb_kuzminsky> and from there to 2.7, using the instructions at
http://linuxcnc.org/docs/2.7/html/getting-started/updating-linuxcnc.html
[11:14:03] <seb_kuzminsky> so the packages are sane on lucid, that's nice
[11:33:08] <cradek> that is dedication
[11:33:39] <cradek> thanks for helping him
[11:34:16] <seb_kuzminsky> eh, it takes like 10 minutes for the whole test, no big deal
[11:59:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/halpath 0a7b242 06linuxcnc 10(5 files in 2 dirs) halcmd: introduce HALPATH, which can be searched for .hal files by halcmd * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0a7b242
[12:03:47] <jepler> not sure that's anything interesting to merge, just going through old branches before reinstalling this machine
[12:04:07] <seb_kuzminsky> heh
[12:15:28] <Tom_itx> i'm running 2.7 on lucid fwiw
[12:15:50] <ssi> tormach is just using the 5i25? Are they just using step/dir signals from it, like a g540 firmware?
[12:16:25] <seb_kuzminsky> ssi: yep, they use the 5i25
[12:16:33] <seb_kuzminsky> not sure what signals they send/receive
[12:16:50] <pcw_home> They have there own firmware to match their custom breakout
[12:17:04] <ssi> gotcha
[12:17:08] <ssi> all stepper machines then?
[12:17:14] <ssi> I thought they were servos for some reason
[12:17:39] <skunkworks> steppers
[12:18:10] <ssi> and they're still doing R8 spindles with the TTS collets?
[12:19:11] <pcw_home> I think thats right
[12:19:30] <skunkworks> anyone think of more videos?
[12:19:31] <skunkworks> http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/283236-cnc.html#post1766484
[12:21:41] * pcw_home 's finger are tired putting on 500 5I25 brackets
[12:22:13] <cradek> that knurling video is just ridiculous
[12:22:17] <cradek> how can that work!?
[12:22:24] <pcw_home> Thats neat
[12:22:25] <skunkworks> cradek, awesome - huih?
[12:22:34] <seb_kuzminsky> pcw_home: isnt that what underpaid interns are for?
[12:22:41] <skunkworks> non-paid..
[12:23:00] <malcom2073> unpaid... no derrrrr
[12:23:05] <ssi> lol
[12:23:25] <ssi> pcw_home: you're selling those things like crazy! :D
[12:23:29] * pcw_home is getting some of proletariat experience
[12:24:37] <ssi> whoa that knurling vid IS cool
[12:24:42] <seb_kuzminsky> you can chill some gold bricks in the freezer to soothe your fingers on later
[12:24:47] <skunkworks> Hot cakes!!
[12:26:23] <Tom_itx> i got a rigid tapping on a sherline
[12:26:45] <Tom_itx> plan to make a better one but first run was in wood
[12:27:29] <ssi> skunkworks: this is good that you put all this together
[12:27:38] <ssi> it's getting irritating hearing people talk about how linxucnc "can't thread"
[12:27:46] <ssi> especially since mach is so bad at it
[12:27:51] <Tom_itx> https://www.youtube.com/watch?v=Jsjde_pKUkk&feature=youtu.be
[12:28:02] <Tom_itx> even on a crappy sherline
[12:28:11] <Tom_itx> with steppers
[12:28:28] <skunkworks> awesome! Did you reverse the spindle by hand?
[12:28:36] <Tom_itx> oh HELL no!
[12:28:42] <Tom_itx> all under gcode commands
[12:28:49] <skunkworks> cool
[12:29:13] <ssi> my g0602 cuts great threads
[12:29:51] <Tom_itx> it's back in the enclosure in the garage now so i can use coolant and cut some alum with it
[12:30:27] <ssi> https://scontent-atl3-1.xx.fbcdn.net/hphotos-xaf1/v/t1.0-9/417616_799707338632_928588899_n.jpg?oh=789e6cd3d02f23894264425c9c400d5b&oe=569B22B5
[12:30:43] <ssi> the lead in/lead out is great for that
[12:31:12] <ssi> https://scontent-atl3-1.xx.fbcdn.net/hphotos-xfa1/v/t1.0-9/427402_795224676922_1395450746_n.jpg?oh=b864f386e3c58fde6bdd652f9d102de4&oe=56AB5BC6
[12:31:20] <ssi> if you ignore the crappy hand-cut slot that was a pretty good screw :D
[12:33:02] <ssi> man I really like the superslant
[12:33:12] <ssi> I almost bought one once but the guy talked me out of it
[12:34:06] <jepler> huh, interesting latency on this machine
[12:34:18] <jepler> big peaks at 0, -5, -10us; no peaks at any positive us
[12:34:40] <jepler> 3.4.9-rtai -- I haven't run rtai realtime in a long while
[12:35:01] <skunkworks> Tom_itx, added
[12:35:16] <Tom_itx> i'll advise when i get a better one
[12:36:36] <ssi> I have a threading vid of my g0602 but it's not great
[12:36:37] <ssi> https://www.youtube.com/watch?v=ywBOYxhBpSI
[12:36:47] <ssi> that's from the dark ages too... almost five years ago
[12:39:34] <skunkworks> Thanks!
[12:43:02] <jepler> http://emergent.unpythonic.net/files/sandbox/jepler-25Sep2015-327.png
[12:43:05] <skunkworks> bbl
[12:43:41] <jepler> errr not sure what the heck that last remark is supposed to mean
[12:44:05] <ssi> jepler: mine?
[12:44:11] <jepler> no, mine about "overhead"
[12:44:38] <jepler> in my latency graph it looks like the servo thread is consistently running early on average, which is weird
[12:44:56] <pcw_home> that is very weird
[12:53:50] <ssi> the hobbing videos are cool too
[12:56:26] <pcw_home> same CPU with Preempt-RT 4.1.7:
[12:56:28] <pcw_home> http://freeby.mesanet.com/4.1.7-e8500.png
[12:56:47] <pcw_home> (done with youtube videos running)
[13:01:32] <ssi> lol going through those videos, "hey that looks like zeeshan's mill". Hit play, annoying zeeshan voice starts, hairy knuckles appear
[13:03:40] <malcom2073> Lol
[13:09:44] <pcw_home> I think TomP had somewhat similar weird results on a Core Duo with RTAI (Same Ebay DC7800 box as I have with a probably slower CPU)
[13:10:40] <ssi> I bought a couple of those ebay 7800s but I haven't gotten around to setting them up
[13:12:00] <ssi> http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/282596-cnc.html sweet someone's doing a 6 axis arm!
[13:12:10] <ssi> blaze that trail guys, I'm gonna need to stand on your shoulders :D
[14:01:44] <jepler> pcw: master branch now has an api for streaming data. this would be nice for fifos in hostmot2 since it allows more than one unit of data to be transferred per thread invocation. but within the 1 packet structure of Ethernet I don't see how to read all available words without ambiguity
[14:02:00] <jepler> any thoughts?
[14:07:18] <jepler> I could use one cycle old data about the fifo level when doing the next read, delaying all data by the thread period
[14:25:15] <skunkworks> what would the fpga do with it?
[14:25:32] <skunkworks> or know what to do woth it
[14:34:57] <seb_kuzminsky> ssi: i have an arm similar to that, mostly working
[14:35:21] <seb_kuzminsky> http://highlab.com/~seb/linuxcnc/scorbot-er-3/
[14:38:11] <ssi> nice!
[14:38:35] <ssi> I still really want one or two of these
[14:38:35] <ssi> http://www.ebay.com/itm/Kuka-Roboter-KR150L-150SP-2-Robot-Arm-No-Controller-/271659536669
[14:39:28] <andypugh> seb_kuzminsky: needs more belts and pulleys :-)
[14:39:35] <ssi> :D
[14:40:06] <seb_kuzminsky> what i really need are mechanical drawings of all the members, so i can poke the link lengths into the kinematics module i wrote for it...
[14:40:37] <andypugh> There is an interesting robot on the forum, it has screws moving rotary joints in a non-linear manner, and the chap wants pumakins to simulate it. I have him exporting extra results from the kins for Vismach to use.
[14:41:24] <andypugh> Does the Inverse kins get called at all in joint mode? His Vismach doesn’t update in joint mode.
[14:41:44] <andypugh> (I can see that it doesn’t need ot be called)
[14:41:56] <cradek> I sure don't know
[14:42:06] <cradek> I agree it doesn't need to be called, so I bet it isn't
[14:42:38] <cradek> er I think you mean forward (joint->world)
[14:42:54] <andypugh> No, I mean world to joint.
[14:43:13] <cradek> in joint mode?
[14:43:15] <cradek> surely not
[14:43:20] <andypugh> There is no need to convert XYZ to joint angles in joint mode
[14:43:26] <cradek> I agree
[14:45:09] <andypugh> Here be the thread.
http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/29664-create-variables-in-function-of-kinematics-values
[14:54:21] <jepler> skunkworks: there are several kinds of serial interfaces in hostmot2, like bspi. internally to the fpga, they have queues for data to be sent and received.
[14:55:01] <jepler> in the current incarnation, you have to jump through hoops to send or receive more than one unit of data in one period.. but now some groundwork has been done in linuxcnc that could improve that limitation.
[14:57:02] <andypugh> jepler: I want to make bspi and uart look like SSi and Fanuc
[14:57:18] <jepler> probably concentrating on the "linuxcnc is sending" side is best to begin with. one use case we know about is sending raster data for laser engraving, where if you could you might want to send an 8-bit intensity value for every 1/300" of motion to get 300dpi grayscale, but that is a data rate higher than 32 bits per 1ms
[14:57:55] <andypugh> In that scenario a faster base thread might be the answer, some of the time.
[14:58:11] <andypugh> But isn’t a very general solution, I guess.
[14:59:29] <jepler> andypugh: I'm not familiar enough with how ssi and fanuc (encoder interfaces?) "look" to see if this is related to my ideas or not
[14:59:45] <andypugh> No, not really at all related.
[15:00:25] <jepler> those two need to receive a fixed amount of data for every position update, I think?
[15:02:48] <andypugh> When I wrote the BSPI and UART drivers I couldn’t see a way to define what the bits in the packet meant, and even then it would have been an enormous amount of work to write a system to send the data to HAL pins created on the fly. But then Smart-serial made on-the-fly HAL pin creation necessary, and I thought up a format for defining the meaning of a bit stream, and so it is now fairly easy to use SSI, and sti
[15:02:49] <andypugh> hard to use BSPI. One is a string in the HAL, the other is a custom driver compoinent.
[15:03:51] <andypugh> UART is always 8 bits. keeping track of which byte of a packet you are in is a puzzle
[15:10:23] <jepler> which what does BISS stand for anyhow?
[15:10:59] <jepler> ok, googled it
[15:11:22] <jepler> The open source BiSS Interface (bidirectional/serial/synchronous) is based on a protocol which implements a real time interface. It enables a digital, serial and secure communication between controller, sensor and actuator.
[15:12:52] <andypugh> I would have to expand the current definition to allow bidirectional. Maybe capital letters for output pins?
[15:13:16] <andypugh> Who am I kidding anyway. I don’t have enough spare time at the moment.
[15:14:24] <andypugh> Tonight I need to write a horizontal millling config for my milling machine.
[15:18:01] <skunkworks> andypugh: your linecurve componant works great!
[15:18:24] <jepler> andypugh: have fun. it's good to talk to you for a few minutes.
[15:19:03] <andypugh> We do nearly everything in the PCMs with those (and the 2D alternative). Modifications to emissions, dyno roller detection, cheaping the EPA, all that sort of thing.
[15:19:35] <andypugh> (Joke, my employer tries hard to be squeaky-clean in those matters)
[15:21:55] <jepler> heh
[15:22:05] <jepler> I am not surprised to hear it's on your mind though
[15:26:20] <PCW> jepler, yes, stream writing is easy since the read can read FIFO free space before the write
[15:26:21] <PCW> for reading data I guess the best you can do without some firmware magic is read the FIFO
[15:26:23] <PCW> data available and then read that the next cycle
[15:31:40] <jepler> keeping an outgoing fifo full is the first order of business, right?
[15:32:07] <PCW> yes, output is probably most useful
[15:32:09] <PCW> I have considered adding a minor protocol hack. with this hack, the lbp16 command "read 0 data items from xxxx" means read all available data items
[15:32:42] <PCW> the return packet of item would have the item count pre-pended
[15:32:49] <PCW> items
[15:33:16] <jepler> yeah, something like that crossed my mind
[15:34:05] <PCW> maybe with the item count register specified in the command
[15:34:10] <jepler> not sure how to make that and pci-style access look the same from an API point of view, it would need a new API we don't have now.
[15:34:32] <jepler> in the hostmot2 hal driver
[15:34:42] <PCW> well PCI just moves the remote code to the driver
[15:36:49] <jepler> yeah I see that in outline
[15:37:01] <PCW> the data count register pointer could be a lbp16 register but I generally dont like saving much state in the remote
[15:38:57] <jepler> in the world where we admit packet reception can be unreliable I wonder what all failure modes FIFOs introduce
[15:40:06] <jepler> if a response to a read packet goes missing, those bits are just gone and not coming back
[15:40:34] <jepler> if a read request packet goes missing, your fifo might overflow
[15:41:02] <jepler> if a write packet goes missing, your fifo might underflow
[15:48:54] <PCW> overflow and underflow are easy (more buffer)
[15:50:44] <PCW> first case is hard with a plain FIFO but maybe possible with some FIFO pointer access
[15:52:07] <jepler> let's just send every response packet twice so that a 1e-6 event becomes a 1e-12 event
[15:52:27] <PCW> :-)
[15:52:49] <PCW> Thats basically what 1GE does
[15:53:19] <PCW> (to get the same error rate as 100BT )
[15:53:54] <jepler> I did not know that
[15:54:55] <PCW> its done in the encoding
[15:56:30] <jepler> so we just need to disable ethernet and udp checksums on reception (this can apparently be done in linux) and build in more FEC
[15:56:52] <jepler> http://stackoverflow.com/questions/22101650/how-can-i-receive-the-wrong-ethernet-frames-and-disable-the-crc-fcs-calcul
[16:04:49] <cradek> jthornton: don't miss the end of
http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/283236-cnc.html#post1766484
[16:18:36] <seb_kuzminsky> heh
[16:18:49] <seb_kuzminsky> come on in, the water's great!
[16:20:36] <cradek> that's a pretty great new feature
[16:26:32] <skunkworks> :)
[16:34:43] <cradek> skunkworks: thanks for doing that thread
[16:36:27] <skunkworks> I like showing off :)
[16:36:38] <andypugh> I do like threas that go “if only….” and you get to say “But that’s already there…"
[16:39:19] <skunkworks> This kinda started because of a thread on the mach yahoo group which pretty much says if you want to do encoder threading with mach - about the only hardware that works right now is the CSMIO something. aprox $700
[16:40:22] <skunkworks> someone started a galil plugin but never finished it.. some other control doesn't pull out at the end of the thread so you need a grove. Css not working - yada yada
[16:40:52] <jepler> to be fair there are likely to be significant limitations on linuxcnc threading (max speeds and feeds) if you don't have an FPGA card
[16:41:07] <skunkworks> then the guy that spent 2000 hours getting threading to work.
[16:41:37] <skunkworks> jepler: I thread with the printer port and 100 line encoder and it works wonderful. (printer port)
[16:41:58] <skunkworks> I do state that the printer port does have its limitations - but it does work quite well.
[16:44:56] <seb_kuzminsky> cradek: i think you're right that the guy with the broken upgrade on the forum this morning ran 'make install'
[16:45:27] <jepler> haven't we put enough warnings on that yet?
[16:45:32] <seb_kuzminsky> that puts things in different places than the debian package does, and specifically puts the linuxcnc.so python module in the place where his broken one is (which is not where the package puts it)
[16:45:48] <skunkworks> I think I sound a bit crazy sometimes...
[16:46:01] <seb_kuzminsky> it you type "sudo make install" it'll totally just cp stuff into your $prefix
[16:46:09] <seb_kuzminsky> skunkworks: if so, you're my kind of crazy :-)
[16:47:03] <jepler> bold
[16:47:03] <jepler> echo "# warning: If you already have an installed linuxcnc, this will #"
[16:47:06] <jepler> echo "# replace an existing installation. If you have installed #"
[16:47:09] <jepler> echo "# a linuxcnc package, this will damage the package. #"
[16:47:12] <jepler> offbold
[16:47:14] <jepler> echo "# hint: To test a self-built version of linuxcnc without damaging #"
[16:47:17] <jepler> echo "# the package version, don't specify a --prefix #"
[16:47:19] <Tom_itx> skunkworks, updated video on the way
[16:47:20] <jepler> I guess we need to implement italic blink too
[16:48:00] <Tom_itx> https://www.youtube.com/watch?v=g99lUtjLfMU&feature=youtu.be
[16:48:10] <Tom_itx> skunksleep you can update your links if you wish
[16:48:18] <seb_kuzminsky> jepler: that's only if there's an installed package
[16:48:51] <seb_kuzminsky> i propose that "make install" should print the warning and exit 1 unless you do some secret handshake
[16:49:17] <seb_kuzminsky> like "REALLY_COPY_STUFF_WILLY_NILLY=1 make install"
[16:52:08] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-WIP-untested-admonish-users-harder-about-make-instal.patch
[16:52:15] <jepler> we already have that variable, it's called DESTDIR=
[16:52:59] <seb_kuzminsky> perfect
[16:53:22] <seb_kuzminsky> that looks like 2.6 material
[16:53:53] <jepler> I'm about to flake out for the day so if you want to test it please be my guest
[16:54:09] <jepler> also my cat says hello
[16:55:02] <seb_kuzminsky> hi cat
[16:56:16] <jepler> see you later
[16:56:20] <seb_kuzminsky> seeya
[17:28:19] <mozmck> why not have "make install" put stuff in the same place the packages do?
[17:57:38] <seb_kuzminsky> "make install" is bad not because it puts things in funny places, but because it bypasses the packaging infrastructure's tracking of what's installed where
[17:58:05] <seb_kuzminsky> so there's no reliable way to query it, or uninstall it (which is what's biting Gaston48 on the forum now)
[18:02:01] <mozmck> I see.
[18:12:53] <KGB-linuxcnc> 03Jeff Epler 05master b62f3d3 06linuxcnc 10src/Makefile admonish users harder about 'make install' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b62f3d3
[18:13:04] <seb_kuzminsky> chickened out (or came to my senses) at the last second
[18:13:05] <seb_kuzminsky> thanks jeff
[18:13:16] <seb_kuzminsky> have a good weekend, all!
[19:38:29] <PCW> A Cheap (read) FIFO trick to allow retries would be to allow read and write of the read data pointer (or local push/pop)
[19:38:31] <PCW> then if a read packet went astray the host could restore the read pointer and try again
[19:47:58] <PCW> or you could turn that around and not advance the read base pointer at all, when reading the FIFO just the temporary index
[19:47:59] <PCW> and then only "commit" the read in the following write cycle if the read data got there safely
[19:48:54] * PCW is likely talking to himself (again )
[19:53:59] <Tom_itx> still good to get it out :)
[19:55:49] <PCW> :-)
