#linuxcnc-devel Logs

Mar 12 2018

10:31 AM sliptonic: If a G2/G3 move on the XY plane is programmed with a Z word (ie a helix). Does the check for 'Radius to end of arc differs from radius to start' take into account the Z movement?
10:33 AM sliptonic: Or is it only checking the radius as if the arc were entirely on the XY plane?
10:33 AM seb_kuzminsky: sliptonic: the radius check is planar, it ignores Z
10:33 AM sliptonic: awesome. Thanks
10:35 AM seb_kuzminsky: the check is here: https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interp_arc.cc#L108-L128
10:40 AM cradek: the Z doesn't affect the starting or ending helix radii
10:40 AM cradek: are you having a problem that leads you to having this question?
10:40 AM sliptonic: cradek: No. I'm writing a helper/test in FreeCAD Path workbench to make sure we don't generate bogus arcs
10:41 AM cradek: ah cool
10:41 AM cradek: every gcode author should be so watchful :-)
10:41 AM sliptonic: The core operations work right but macro writers keep getting tripped up.
11:54 AM jepler: sliptonic: by the way, are you aware of the "rs274" program, so that you can test gcode fragments without having to fire up LinuxCNC? It's very handy. "rs274 -g" can take input on stdin (Default) or from a named file
11:55 AM jepler: for example, a full-circle arc touching the origin: printf 'G0X0Y0Z0\nG2I1F100\nM2' | rs274 -g
11:55 AM jepler: hmm I'm an hour late :-P
11:56 AM sliptonic: jepler: I was not aware. Thank you!
01:50 PM seb_kuzminsky: i used rs274 in the test suite for svg2gcode, it's great
01:51 PM seb_kuzminsky: https://github.com/SebKuzminsky/svg2gcode/blob/master/test/runtests#L56-L63
02:18 PM skunkworks: what are peoples thoughts on ruby?
02:18 PM skunkworks: and go
02:31 PM jepler: For me, I don't know what itch ruby would scratch that Python doesn't -- they're both in that broad family of interpreted, dynamic-typed languages.
02:34 PM skunkworks: that makes sense. we have a guy here that loves ruby and thinks we should do all of our internal applications in ruby on rails.
02:35 PM skunkworks: I don
02:35 PM skunkworks: I don't have feels for it yet.
02:36 PM skunkworks: (other than I have to fix what he breaks in his little application he made.. ) ;)
02:36 PM skunkworks: (or that might be his way of getting into it - I don't know)
02:37 PM mozmck: I've rarely seen any ruby outside web stuff.
02:38 PM skunkworks: he started with ruby for some internal glue stuff he did.
02:41 PM skunkworks: looks powerful - and runs on both windows and linux..
03:18 PM sync: pcw_home: how fast can a 6i25 output and input stuff?
03:22 PM pcw_mesa: you mean data rate or PCI access time?
03:22 PM rene-dev: pcw_home: is it possible to use memory mapped IO on a mesa card?
03:23 PM pcw_mesa: all hostmot2 PCI cards are memory mapped
03:23 PM rene-dev: ah, ok. I never looked at the hm2_pci driver....
03:23 PM rene-dev: so can the fpga access host memory?
03:25 PM pcw_mesa: on 5I25/6I25/5I24/6I24 not with standard firmware (which is PCI target only)
03:25 PM rene-dev: Im thinking of using a mesa card as eeprom emulator. but the fpga does not have the blockram to hold the image. so crazy idea is to have the fpga fetch the data from host memory.
03:26 PM rene-dev: I need the data available after 14ns
03:26 PM pcw_mesa: on 5I23 yes (PLX chip has DMA controller) and can do maybe 80 Mbytes/second
03:29 PM pcw_mesa: you might be better off with a FPGA dev board with on card SDRAM (pretty common)
03:30 PM sync: well, yeah but I guess mmio would be fast enough to do it
03:31 PM pcw_mesa: if the target does random access you may be screwed by DMA latency
03:32 PM rene-dev: Its very random.
03:32 PM rene-dev: XC6SLX45 could do it in blockram...
03:41 PM pcw_mesa: I'd really like an excuse to use the Artix chips, the XC7A15 all the way to XC7A100 are available in the FTG256 package
03:41 PM pcw_mesa: (and from XC7A15 up to XC7A200 in the 484 pin package)
03:43 PM pcw_mesa: plus our little embedded processors meet timing at 200 MHz in Artix
03:45 PM jepler: rene-dev: how big an eeprom are you emulating?
03:48 PM pcw_mesa: Also how about on the fly decompressing?
03:49 PM rene-dev: pcw_mesa: 2Mb
03:51 PM jepler: digilent's "Arty A7" (100USD) has "256MB DDR3L with 16-bit bus @ 667MHz". If I found the right datasheet for the RAM it's CL 7, which is already 8.75ns
03:52 PM rene-dev: not easy, we also need on the fly editing...
04:05 PM pcw_mesa: DDR SDRAM may be to slow to emulate fast random access ( is this serial EEPROM? )
04:07 PM jepler: You need a couple of 2mbit SRAMs. FPGA can write to one while device is treating the other as its EEPROM. Swhich one gets to drive the real device bus by FPGA after an on-the-fly edit operation has completed.
04:08 PM jepler: Swhich = switch
04:13 PM sync: yes, but that is the boring way
04:15 PM pcw_mesa: you're in the 40-50 ns random access region with SDRAM unless the whole image will fit in one row (plus refresh may cause pain and suffering)
04:16 PM pcw_mesa: that may be ok for serial EEPROMS
04:16 PM jepler: rene-dev already stated 17ns, so I'm assuming it's not serial
04:17 PM pcw_mesa: yeah so probably only blockRAM
04:17 PM rene-dev: I guess thats the only way to go.... that fpga is expensive, but not too bad.
04:18 PM rene-dev: I just hoped there would be some mmio magic so we could use the hosts memory :D
04:41 PM pcw_mesa: its a real time problem :-) latency not throughput
04:41 PM rene-dev: I know :)
09:50 PM jepler: digitalocean's, dnspython's, and bind's ideas of what DNS zones look like are just different enough to make the task of "sync a whole zone file to a digitalocean domain via API" not as simple as you'd wish
09:51 PM jepler: for example, "www IN CNAME web" isn't valid to DO, because "web" doesn't end in a dot. But on the other hand, when you create www IN CNAME web.example.com. and query it back, you get the data as "web.example.com", no dot !?
09:53 PM jepler: (in bind, www IN CNAME web would be the same as www IN CNAME web.example.com. if you're in the zone file for web.example.com.)
09:53 PM jepler: (er, for example.com.)