#linuxcnc-devel Logs

Jan 24 2018

12:19 AM seb_kuzminsky: skunkworks_: i put a dxf2gcode deb here:
12:21 AM seb_kuzminsky: http://highlab.com/~seb/linuxcnc/dists/stretch/main/binary-all/dxf2gcode_20170925-2_all.deb
12:21 AM seb_kuzminsky: it seems to run fine, but so far *all* the gcode i've generated with it has failed to run due to various problems
12:21 AM seb_kuzminsky: :-(
03:11 AM -!- #linuxcnc-devel mode set to +v by ChanServ
06:57 AM skunkworks_: what kind of issues? I just did a quick conversion without changing anything (I need to setup the safe hight and stuff I guess)
06:59 AM skunkworks_: seb_kuzminsky, http://electronicsam.com/images/KandT/testing/dxf2gcode.png
07:00 AM skunkworks: I remember this from last time - if the dxf file doesn't have $INSUNITS set it comes in as MM by default
08:43 AM seb_kuzminsky: i was trying to use cutter comp and it was messing up the entry moves
08:43 AM seb_kuzminsky: then without cutter comp it forgot g91.1 and all the arcs were wrong
08:43 AM seb_kuzminsky: and then i went to bed disheartened
08:47 AM skunkworks: heh - I resemble that
08:50 AM skunkworks: I just replaced a mother board on a pentium 4 machine that is dedicated to run a piece of equipment. Ended up being the newish power supply we replaced a month or so ago.
08:50 AM skunkworks: It can't be the power supply I say - it just can't be.
08:50 AM skunkworks: well - now we do have a backup motherboard.
09:23 AM seb_kuzminsky: did you get dxf2gcode running or is that from the deb?
09:23 AM skunkworks: seb_kuzminsky, did you have stretch rtai debs? (I remember you had worked on them but they crashed the buildbot) - I could try it on real hardware or was there some other glaring problem
09:24 AM skunkworks: I got it running by using pip to isntall the pyqt5. I will try your deb soon
09:25 AM seb_kuzminsky: yeah there's linux-4.4/rtai-5.0 debs in the debian archive at highlab
09:25 AM seb_kuzminsky: they're in the jessie dist, but i think there's a good chance they'd work on stretch
09:26 AM seb_kuzminsky: the problem is they sometimes hang on unload :-(
09:26 AM seb_kuzminsky: do you have a machine that doesn't do well enough with rt-preempt?
09:27 AM seb_kuzminsky: for pyqt5 i made dxf2gcode Depend on python3-pyqt5, it gets installed via apt and everything qt-related works in my testing
09:34 AM seb_kuzminsky: hmm i just tried to hit R for run in skunkworks screenshot of Axis, maybe i should just go back to bed
09:35 AM skunkworks: I have done that many times... or tried to close it from the image...
09:36 AM hazzy: seb_kuzminsky: Just installed the deb for dxf2gcode you linked above on Stretch, everything seems to be working fine.
09:52 AM seb_kuzminsky: cool
09:52 AM seb_kuzminsky: have you made any parts with dxf2gcode, or is it early-stage experimentation at this point?
09:52 AM seb_kuzminsky: i saw a post on their mailing list of a part someone milled
09:53 AM Roguish: seb_kuzminsky: hey, got my x back. even got 2 monitors running once I got the proper hdmi-to-vga adapter, and installed 'arandr'
09:53 AM seb_kuzminsky: nice!
09:54 AM Roguish: now to get a separate 'preview' screen running.
09:57 AM seb_kuzminsky: second post in this thread: https://groups.google.com/forum/#!topic/dxf2gcode-dev/Snh802YqQos
09:59 AM hazzy: Roguish, there is a stand alone preview widget that should work
10:01 AM Roguish: link?
10:02 AM hazzy: I think it is in lib/python, let me find it
10:06 AM seb_kuzminsky: gremlin?
10:07 AM seb_kuzminsky: gremlin_view
10:07 AM seb_kuzminsky: start it after linuxcnc is started and it opens a backplot/preview window in addition to the normal GUI
10:12 AM hazzy: You have at least two options, gremlin_view, (which I had forgot about) and gremlin-run in src/emc/usr_intf/gremlin/
10:13 AM hazzy: You have to pass the path to the INI to gremlin-run: ./gremlin-run path-to-ini
10:15 AM hazzy: I can't get a preview to load in gremlin-run though, so maybe it just works as a plot while running?
10:20 AM skunkworks: I think dxf2gcode doesn't do holes yet - which was another pain. I don't know if that had been added yet
10:20 AM skunkworks: (drilling holes)
10:22 AM skunkworks: hmm - they might have fixed that now
10:35 AM seb_kuzminsky: i think they do have some special hole handling now
10:38 AM skunkworks: Yes - you call the prefix the layer name as DRILL
10:57 AM mozmck: pcw_home: are you around?
11:01 AM pcw_home: yeah
11:03 AM mozmck: It seems like the M25P16 eeprom are all obsolete and vanishing - is there a good alternative?
11:05 AM pcw_home: let me see what we are using now...
11:09 AM pcw_home: looks like we are using Fremont Micro Devices FT25H16S-RT
11:11 AM mozmck: Thanks! Looks like everyone is trying to discontinue them.
11:14 AM pcw_home: theres also Adesto Winbond, Macronix
11:15 AM mozmck: Octopart suggested several chips as possible alternatives. Microchip has a SST25VF series - do you know if they are compatible?
11:15 AM pcw_home: microchip if you dont mind paying 5X
11:16 AM mozmck: Huh, they didn't look too bad from what I saw so far.
11:16 AM pcw_home: _probably_ compatible I have had good luck with the Fremont parts so far (the Spansion/Cypress parts had some random issues)
11:17 AM mozmck: I see. I was looking at Cypress but those look to be obsolete as well.
11:18 AM pcw_home: I would avoid the Cypress parts, about 1% may start wrong depending on power supply ramp-up
11:19 AM mozmck: I see. Thanks for the tip.
11:19 AM pcw_home: the Fremont parts are really fast to program/erase also
11:19 AM pcw_home: maybe twice as fast as Cypress/Spansion/ST
11:20 AM mozmck: Nice!
11:21 AM pcw_home: (we started with ST then they went obsolete, then we uses Spansion/Cypress but they are buggy, last fremont, I have tried Macronix I think and they were OK
11:22 AM pcw_home: I think the low capacity ones have been abandoned by US/European manufacturers since the have gotten so cheap
11:24 AM mozmck: I see. Would the higher capacity chips work instead?
11:24 AM pcw_home: sure, you can always use a 64 MB one and have 16 configs...
11:25 AM mozmck: I see. I guess that's always and option then if you just can't get the 16 mb
11:25 AM mozmck: On another note (maybe related?), I've noticed some issues when programming the eth eeprom - if the board name and ip are already programmed and I try to do it again, sometimes it will fail and I have to re-power the board to connect to it. Have you seen something like that?
11:25 AM pcw_home: do you clear the arp cache?
11:26 AM mozmck: no, because I don't even know what that is! I'm using linux btw.
11:26 AM pcw_home: ( you cant change the MAC address out from under the OS without cleanup )
11:28 AM mozmck: Hmm, that could be it. It happens even if I'm trying to write the same MAC, and before I ever get there, but maybe it's because I just wrote a MAC...
11:28 AM pcw_home: arp -d
11:29 AM mozmck: I'll try that and see. I think I sent you my python script to do the programming. I just about have it down to running that script and it will do everything (after the intial JTAG programming).
11:29 AM pcw_home: arp -d 192.168.1.121
11:30 AM pcw_home: yeah I have that in my init script otherwise it will hang (until the arp cache times out)
11:31 AM mozmck: I even found (and modified) a program to print the MAC address to a brother label printer. That needs a little work, but is close.
11:31 AM pcw_home: also the MAC is only read on reset/powerup/reconfig
11:31 AM pcw_home: ( EEPROM MAC address I mean )
11:32 AM mozmck: I'll try adding the arp command and see if that helps. Thanks for the help!
11:33 AM pcw_home: NP
11:34 AM pcw_home: Also beware that on first initialization, the MAC address is whatever is in the EEPROM (Usually 0xFFFFFFFFFFFF)
11:35 AM pcw_home: some switches will not forward packets with that address (I should fix that in the firmware)
11:39 AM pcw_home: I tried before (by setting just the MS byte to 00) but someone wanted their own crazy MAC address and couldn't set it
11:40 AM pcw_home: so I backed that change out, I probably should check for 0xFFFFFFFFFFFF and supply a valid MAC address in that specific case
11:41 AM pcw_home: or have a "EEPROM Valid" seal
11:48 AM mozmck: I'm not using a switch for programming so that hasn't been a problem - but thanks for the heads up.
11:52 AM pcw_home: I just changed to an older dumber switch...
11:53 AM mozmck: Heh, smarter is not always better.
11:53 AM mozmck: I have a custom rs485 hub that I made too smart and have had to dumb it down.
11:54 AM pcw_home: beware if you use the generic address and might have other FPGA cards on the network... Ive programmed the wrong card more than once...
11:56 AM mozmck: Heh! We will just directly connect to the computer that will do the programming. I put in a NIC for the programming IP (192.168.1.121) and one for the testing IP (10,10,10,10)
11:25 PM linuxcnc-build: build #2485 of 1903.clang-wheezy-amd64 is complete: Failure [4failed apt-get-update install-missing-build-dependencies compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/2485 blamelist: Sebastian Kuzminsky <seb@highlab.com>
11:31 PM seb_kuzminsky: awesome