#linuxcnc-devel | Logs for 2019-03-03

Back
[01:00:10] -!- c-log has quit [Ping timeout: 246 seconds]
[01:02:38] -!- c-log has joined #linuxcnc-devel
[01:29:00] -!- ve7it has quit [Remote host closed the connection]
[02:07:42] -!- c-log has quit [Ping timeout: 250 seconds]
[02:10:45] -!- c-log has joined #linuxcnc-devel
[07:44:04] -!- whitequark has joined #linuxcnc-devel
[08:04:52] <whitequark> rmu: afaict i'm interested in get_pos_cmds() and output_to_hal() here https://github.com
[08:05:33] <whitequark> which do the job of calling the tp and writing to hal
[08:07:07] -!- c-log has quit [Ping timeout: 245 seconds]
[08:08:58] -!- c-log has joined #linuxcnc-devel
[08:31:27] <rmu> whitequark: sorry, i'm currently cleaning up / reorganizing the workshop, AFK most of the time
[08:32:13] <rmu> whitequark: if you want to do all real time stuff in FPGA you probably want to extract the segments (lines and circles) out of the TP.
[08:33:30] <rmu> usually, the segments are fed into one of two functions (ramp accel and trapezoidal accel), that would be the parts that have to be run under realtime constraints and generate position/velocity updates
[08:33:47] <rmu> rigid tapping will need some extra logic
[08:34:00] <whitequark> ohh i see what you mean
[08:38:07] <rmu> in my experiments (see here https://forum.linuxcnc.org) i stumbled upon some strange situations where the TP changed segments at a very late stage and/or generated segments that did not meet exit velocity constraints, with my hacked-together acceleration profile these situationes generated acceleration violatins
[08:38:25] <rmu> unfortunately i didn't have time to dig deeper and clean up my code
[08:39:19] <whitequark> rmu: ok, so i'm thinking of a kind of "multi-phase" experiment
[08:39:41] <whitequark> phase 1 would be replacing parport, phase 2 would be replacing stepgen, phase 3 would be taking segments off the TP directly
[08:40:11] <whitequark> actually i'm wondering if an USB LPT adapter that actually works for linuxcnc would be a useful product on its own right
[08:41:02] <whitequark> it's simple enough you could do it with a toner transfer PCB process even
[08:41:11] <whitequark> unsure if there's demand but i know exactly how i would make it
[08:44:23] <whitequark> oh interesting http://ecklersoft.com
[08:44:30] <rmu> replacing parport and stepgen is easy, very easy on ARM boards like raspberry pi.
[08:45:12] <whitequark> yeah i know, but the point is not to use some board with cheap GPIO (i know that's easily done)
[08:45:24] <whitequark> but to validate the realtime usb stuff without spending too much on custom hal modules
[08:46:26] <rmu> it should be possible to talk USB from hal module with rt-preempt kernel
[08:47:52] <whitequark> the pymini person extracted the tp from linuxcnc in a rather ad hoc way, but they don't need any rt bits at all. hmmm.
[08:48:06] <whitequark> i can see the appeal of that but i also want to reuse linuxcnc
[10:23:33] <rmu> i think the parts of the trajectory planner that depend on realtime need to be fixed anyways...
[10:37:26] <pcw_home> Some parts will always need realtime though (spindle synced motion etc)
[10:38:21] <pcw_home> adaptive feed
[10:44:52] <pcw_home> similar situation with hal, if you dont implement hal or something like hal in real time, things like plasma THC are awkward
[10:47:21] <pcw_home> a buffered system like mach (non real time host talking to small real time motion engine) means that any real time feedback needs to be implemented in the attached real time engine
[10:47:59] <rmu> i think that is what whitequark is contemplating
[10:48:12] <whitequark> yeah
[10:48:45] <pcw_home> Yeah its nice in that its host agnostic but not so great for more complex controls
[10:48:49] <whitequark> when you're talking about plasma THC, do you mean e.g. "torch on/off" commands?
[10:49:04] <rmu> spindle synced motion in combination with feed- and spindle-speed-override quickly gets awkward to handle
[10:49:34] <pcw_home> no, real time Z axis motion based on plasma voltage feedback
[10:49:42] <rmu> you want to control torch height (via z-axis) depending on arc voltage
[10:50:16] <whitequark> oh I see
[10:50:51] <whitequark> right so the idea with Glasgow is that it takes care of all the annoying parts of FPGA toolchains (by cutting very carefully measured corners).
[10:51:16] <pcw_home> all these things are possible but you sort of end up re-implementing linuxCNC/HAL on the remote device
[10:51:18] <whitequark> one aspect of it is that something like torch height control (assuming you have some kind of ADC for that) is maybe a few added lines of code
[10:51:30] <pcw_home> its not...
[10:51:37] <pcw_home> THC is complex
[10:52:15] <whitequark> well, you have a transfer function with feedback. if you can define it in integer domain, it's not hard to add
[10:52:59] <whitequark> it's no point arguing, I'd much rather write a PoC for complex feedback on FPGA. worth a thousand words.
[10:53:03] <pcw_home> THCs are much more complex (corner locking, kerf crossing etc etc)
[10:53:40] <whitequark> ohh I see
[10:53:44] <whitequark> that's interesting then.
[10:53:48] <pcw_home> hal, unlimited floating point make this easier to do
[10:54:53] <pcw_home> there is a very large set of linuxCNC uses that dont need these features (routers etc)
[10:54:54] <whitequark> new plan: instead of replacing HAL, extend HAL into the FPGA, by making it possible to define HAL signals across the USB interface.
[10:55:40] <rmu> rt-preempt kernels are not that problematic if you have real hardware
[10:56:17] <pcw_home> yes, I suspect that (remote hal) is a better choice (unless you only aim at simple targets)
[10:56:28] <whitequark> I assume this plan would need rt-preempt anyway, since HAL is based on rt
[10:56:59] <whitequark> remote HAL, hmm.
[10:57:24] <whitequark> it's kind of annoying here that HAL is polling driven
[10:58:29] <whitequark> logically, I have a stream of tuples with every HAL parameter used, which on each cycle are compressesd (by differentiating against previous tuple), and queued into the device. then the same on the other side for inputs.
[10:59:23] <rmu> are you sure compression is worth it? USB should not have a bandwidth problem, there is not that much data to transfer
[10:59:42] <whitequark> 2 points on this.
[11:00:37] <whitequark> first, it's not real compression, more just not sending the data you don't need. if nothing else, this helps with debugging.
[11:00:45] <whitequark> second, you'll be surprised how many problems USB has.
[11:00:51] <whitequark> honestly, it is mostly problems.
[11:01:07] <rmu> that's the reason nobody did a linuxcnc usb interface yet
[11:01:26] <whitequark> the bounded latency transfer mode it has doesn't have guaranteed delivery, and the guaranteed delivery mode doesn't have bounded latency.
[11:01:50] <whitequark> this is -in spite of- the bus and host controllers allowing reserving chunks of bandwidth, -and- the bus inherently having no conflicts as it is driven by host using timeslots.
[11:02:08] <rmu> look at hostmot2 and pico servo interfaces for polled vs. interrupt transfers. both possible with hal.
[11:02:25] <whitequark> USB is like if someone had a box with bus LEGOs and decided to make the worst possible bus out of that.
[11:02:37] <whitequark> you trade off so many useful potential features, and receive a negative return on it.
[11:02:47] <rmu> but it's cheap
[11:02:57] <rmu> no firewire-patent-tax
[11:03:12] <whitequark> but it's so utterly, pointlessly horrible on every level.
[11:03:21] <whitequark> why in the actual hell does it use NRZI with bit stuffing?
[11:03:24] <whitequark> was 8b10b too hard?!
[11:03:35] <whitequark> now your physical packet length depends on the data inside the packet.
[11:03:51] <whitequark> you can't even decode a packet in constant time unless you know what's inside!
[11:04:30] <whitequark> and I mean, sure, maybe it saved someone five hundredths of a cent per chip in 1993, but there's no excuse to keep that in USB 2.
[11:04:38] <whitequark> it's a differential bus, but it's *also* dc coupled.
[11:04:40] <rmu> use ethernet then
[11:05:10] <whitequark> moreover, it has differential states interacting with dc coupled states, which means you can't even use a differential transceiver to implement it.
[11:05:32] <whitequark> you *have* to implement it as two single ended transceivers, with a sort of differential kludge on the side.
[11:06:17] <whitequark> I could go on for weeks.
[11:06:20] <whitequark> anyway.
[11:07:35] <whitequark> Ethernet is good and all but it doesn't improve things a lot.
[11:08:05] <rmu> somehow reminds me of https://youtu.be
[11:08:18] <whitequark> Ethernet doesn't have guaranteed delivery unless you build it yourself, and the latency, instead of depending on your utterly broken OS driver stack, also depends on your utterly broken network hardware.
[11:08:32] <whitequark> I bet if I used Ethernet, someone would try to use remote HAL over public WiFi, and complain.
[11:08:44] <rmu> just use 1:1 connection to dedicated network card
[11:09:19] <whitequark> I have a laptop that has three USB ports and that's it.
[11:09:37] <rmu> usb ethernet dongle then :P
[11:09:44] <whitequark> (ok, one of them is technically Thunderbolt, but Thunderbolt is also batshit insane and I'll leave it as that. I am unfortunately very well aware of it.)
[11:09:47] <whitequark> that doesn't work.
[11:09:58] <whitequark> that gives you all the problems of USB *and* Ethernet.
[11:10:06] <rmu> it was a joke
[11:10:15] <rmu> there is no perfect solution
[11:10:38] <whitequark> I would have used Ethernet if all computers still had dedicated Ethernet ports, but the world has sadly moved on to really thin laptops.
[11:10:42] <whitequark> which I also really like.
[11:10:49] <rmu> simple, cheap, sane, correct. chose 1.
[11:11:06] <whitequark> if they made an USB type C SGMII alternative mode, we *would* have a sane solution to this that works perfectly well.
[11:11:13] <whitequark> I've dug out the proposal someone made for it.
[11:11:58] <whitequark> no one involved with USB type C was interested, which is unsurprising, because everyone involved with USB-C ranges from terminally incompetent to shouldn't go near a single electronic device much less a sheet of paper with "specification" written on it.
[11:12:04] <pcw_home> I ran one of our Ethernet cards on a USB Ethernet dongle, it worked ok for maybe an hour until it tripped over its shoelaces...
[11:12:26] <whitequark> I could tell you *so much* about the absolute worst aspects of USB and Thunderbolt.
[11:13:00] <whitequark> the only way Intel was able to keep Thunderbolt from falling apart is by mandating that every certified TBT3 device follow the exact schematics of one of the ~five Intel reference designs. down to individual BOM lines.
[11:13:12] <whitequark> if you don't do that, they sue you off the market with their patent pool.
[11:13:23] <whitequark> that should tell you everything you need to know about Thunderbolt.
[11:14:14] <whitequark> (also, when you plug a TBT device in, for it to work, you need USB PD--that's power delivery, EC, ACPI, SMM, and OS to cooperate. at *least* six different firmwares are involved.)
[11:14:17] <rmu> for a typical machine, you would need to transfer around 100 bytes max in either direction with 1kHz update rate, and if something bad happens for long enough you "just" have to E-Stop from the FPGA side.
[11:15:05] <whitequark> right, so bandwidth is not really a problem
[11:15:38] <whitequark> the thing about USB is that it's based on timeslots, and it actually doesn't matter a lot *how* much data you transfer.
[11:15:50] <whitequark> what does matter, is in how many packets, and so timeslots, it will end up being split.
[11:16:07] <whitequark> on certain configurations, I could take up most of the bus bandwidth with 1000 bytes per second.
[11:16:13] <rmu> if you generate steps in the FPGA jitter of this 1khz update will not be that critical and missing some updates usually is not catastrophic
[11:16:14] <whitequark> well, enough to make it unusable.
[11:16:24] <pcw_home> even for more bandwidth heavy uses (laser painting) its still pretty small
[11:17:19] <whitequark> the problem with USB isn't so much that it has not enough bandwidth (more than enough) or that it doesn't guarantee latency (it's usually pretty good), it's that it has a lot of strange behavior that makes it work very much not like a FIFO
[11:17:50] <pcw_home> yeah if you assume you motion engine is running in velocity mode, rather ragged updates are ok
[11:18:18] <whitequark> question.
[11:18:49] <pcw_home> as long as you send TP timestamps...
[11:19:24] <whitequark> what's better, low but unbounded average latency with high jitter, or low and bounded latency for almost all requests and even higher spikes in rare circumstances?
[11:19:56] <whitequark> you always have to account for the case where you send an update and it never arrives, but you can trade it off a bit.
[11:20:32] <whitequark> former: plain bulk requests. latter: isochronous requests with a framing on top of them that ensures guaranteed delivery.
[11:21:52] <whitequark> what you *want* is bulk requests with a chunk of bus bandwidth explicitly reserved for them, and it's even possible to implement in a hacky sort of way, but no OS will actually let you do that, because that'd actually make USB useful.
[11:22:26] <whitequark> so you have to choose between sharing bandwidth with a mouse, and handling packet loss in software.
[11:22:58] <rmu> i don't know. assuming usb soundcards use isochronous transfers i would use that, never seem to have problems with that (no glitches to hear)
[11:23:16] <whitequark> there are two problems with isochronous transfers
[11:23:22] <rmu> but it is reasonable to assume that the CNC machine is on one dedicated USB bus
[11:23:43] <whitequark> first, they're buggy as hell in every OS and every device. that USB Audio works at all is nothing short of a miracle, and almost every complex configuration doesn't work well.
[11:23:52] <whitequark> e.g. there are USB sound cards that only work on specific USB host controllers.
[11:24:09] <pcw_home> Preempt-RT hosts are much like the latter: http://freeby.mesanet.com
[11:24:28] <whitequark> second, isochronous transfers don't even *try* to acknowledge the transfer.
[11:25:00] <rmu> complex configuration don't work because of other aspects, not the transfers i assume
[11:25:02] <whitequark> the host controller *could* in theory be able to tell you if the packet went nowhere in reality, but it's not in the spec, so even though that information would have been trivial to request, it's impossible.
[11:25:06] <whitequark> no, the transfers.
[11:25:22] <whitequark> all the host controller does is schedules transfer from a linked list of DMA buffers
[11:25:41] <whitequark> you'd think that's hard to screw up, but wait until you see USB HCs.
[11:26:11] <whitequark> then the OS adds a few layers of crap on top of it and well
[11:26:42] <whitequark> libusb on Windows is like 1/5 as fast as libusb on Linux and glitches out constantly, and as far as I can tell that's not really fixable for the most part
[11:26:48] <pcw_home> Often in RT stuff, dropped data is simple ignored, where its important (things that change remote state) higher level handshaking should be used
[11:27:37] <whitequark> yep, so if I went for isochronous and a generic remote HAL mechanism, I would need to implement this handshaking on top of USB.
[11:28:04] <whitequark> I'd optimistically send all data as it comes to my remote HAL implementation, and then if it turns out there's a missed packet, I have to resend all of the buffered data.
[11:28:24] <rmu> or just ignore the missed update
[11:28:59] <whitequark> this, of course, is a problem, because USB isochronous transfers aren't elastic. you can't opportunistically give the bus a bit more data this cycle, in hope that it'll fit, you have to pre-reserve all of the bandwidth, and all of it will actually get used.
[11:29:06] <rmu> so you would need some kind of framing mechanism so you FPGA side recognizes begin of an update frame regardless of possible garbage and drops in between
[11:29:20] <whitequark> even worse, you can't even ask the host how much free bandwidth it has.
[11:29:26] <pcw_home> even there, there are only a couple of critical things that are not constantly re-sent
[11:29:27] <rmu> and some kind of watchdog that E-Stops the whole shebang if no update is receive within 100ms or so
[11:29:57] <whitequark> all real devices export a zillion isochronous interfaces and then enumerate between them until the HC/OS finally considers one acceptable.
[11:30:06] <whitequark> of course, when this breaks, it's impossible to debug, too
[11:30:43] <whitequark> hmm.
[11:30:55] <whitequark> I imagine it'd still be cleaner to use an isochronous endpoint...
[11:31:24] <whitequark> 16:29 < rmu> so you would need some kind of framing mechanism so you FPGA side recognizes begin of an update frame
[11:32:01] <whitequark> you don't need framing, because USB packet drops will never cause your boundaries to shift arbitrarily
[11:32:08] <whitequark> 16:29 < pcw_home> even there, there are only a couple of critical things that are not constantly re-sent
[11:32:29] <whitequark> but, you need some mechanism to separate the HAL data that can be dropped, vs HAL data that will need to be sent again.
[11:33:22] <rmu> if your motion control is in the FPGA it should not be that critical if you miss one update from the PC.
[11:34:03] <whitequark> if this is an update to something like "turn coolant on" it better arrive at some point
[11:34:36] <whitequark> hmm, I can see why the compression scheme I described above would be problematic.
[11:34:44] <rmu> you transfer the complete input/output process data each update cycle
[11:34:48] <whitequark> if *every* frame would include *every* HAL wire, I wouldn't need that
[11:34:48] <whitequark> yeah
[11:35:30] <pcw_home> That really should be done in LinuxCNC AFAICR the only critical (non duplicated) data sent is the mode setting for index encoder index detection or setup information
[11:35:31] <whitequark> that would simplify everything considerably, and actually make using isochronous fairly straightforward.
[11:35:55] <whitequark> rmu: thanks for this input, I will now design this thing in a completely different way.
[11:36:03] <rmu> my "big" cnc machine has about 80 digital inputs and 120 digital outputs, 4 axis (that's a couple of float per axis) and thats it.
[11:36:05] <whitequark> than I originally intended.
[11:36:11] <rmu> so not much to transfer really
[11:36:22] <whitequark> yes, it easily fits into one isochronous packet... let me look it up...
[11:36:53] <rmu> timestamp everything, and just keep sending. anything missed -> ignore.
[11:37:15] <rmu> looking forward to some updates ;)
[11:37:45] <whitequark> right, so the *minimum* meaningful isochronous packet size is 1024 bytes.
[11:37:55] <whitequark> if you have more than 1K of HAL parameters that's something very unusual.
[11:38:27] <rmu> that's probably an extreme edge case you can safely ignore
[11:38:41] <whitequark> I think I can get the latency down to 1/2 ms. definitely under 1 ms.
[11:39:12] <whitequark> not less than 1/4 ms under any circumstances, for a roundtrip.
[11:40:22] <rmu> you can decouple reading of inputs from your transfers
[11:41:05] <rmu> (snapshot at a specific time, synchronise via PLL with host)
[11:42:06] <whitequark> can you elaborate on that?
[11:42:55] <whitequark> the PLL is not needed, as the latency of output-to-input loop (for example) is constant and depends only on the FPGA gateware, provided the gateware is done correctly
[11:43:05] <whitequark> but I'm curious about the synchronization you propose.
[11:43:45] <rmu> assume you have a link that has some jitter, then it can make sense to trigger a "snapshot" of inputs independently, running with some exact clock
[11:44:02] <whitequark> ahh, I see what you mean.
[11:44:04] <rmu> so your inputs are always sampled at a precise interval
[11:44:25] <pcw_home> We do this on our Ethernet cards (for example when LinuxCNC is running the PID loop, and we want jitter free sampling of the encoder position)
[11:45:06] <whitequark> yes, that would of course be useful. the input sampling would be done at exactly the isochronous packet rate.
[11:45:09] <pcw_home> well jitter reduced...
[11:45:21] <whitequark> the FPGA is normally running synchronous to USB clock, so that's fairly easy.
[11:46:03] <pcw_home> this works pretty well because of the jitter statistics
[11:48:39] <whitequark> I'm currently thinking of taking my 3D printer, throwing out the Arduino junk it came with, and replacing everything from the G-code parser down to and including FET drivers with my FPGA board.
[11:48:47] <whitequark> do the chopping and dead time generation in gateware too, why not.
[11:55:30] <whitequark> hmm, so a fun thing to do would be to make the USB device self-describing.
[11:56:28] <whitequark> you load a HAL module, it finds the device, pulls the HAL wire definitions out of it.
[12:43:50] -!- ve7it has joined #linuxcnc-devel
[13:35:27] <whitequark> is there an intro to rt-preempt that you would recommend?
[13:36:16] -!- c-log has quit [Ping timeout: 250 seconds]
[13:37:50] -!- c-log has joined #linuxcnc-devel
[13:38:02] <rmu> I only know the linuxfoundation wiki https://wiki.linuxfoundation.org
[13:39:23] <rmu> but building a hal module is pretty easy, then the rt stuff is taken care of
[13:44:34] <whitequark> i'm wondering about the use of usb from realtime domain
[13:44:43] <whitequark> i mean, the whole thing is a hal module
[13:45:06] <whitequark> if it has any other component in linuxcnc, it'd just request the wire format via usb
[13:45:44] <whitequark> hang on
[13:46:27] <whitequark> rmu: if i'm using rt-preempt is there any benefit to doing the hal component as a kernel module as opposed to an userspace process?
[13:56:16] <pcw_home> I dont think so (all normal hal RT modules are userland AFAIK unless you are using RTAI)
[13:56:37] <whitequark> oh well, that simplifies my job massively
[13:56:54] <pcw_home> also makes them much easier to debug
[13:58:13] <whitequark> >In a Run-In-Place build, the LinuxCNC programs are compiled from source and then run directly from within the build directory. Nothing is installed outside the build directory.
[13:58:18] <whitequark> I love this
[13:58:31] <whitequark> I was dreading installing something to /usr/local
[13:58:48] <whitequark> I think that step alone made me like linuxcnc twice as much
[14:11:31] <Tom_L> pretty soon you may wanna just use it as it is
[14:12:41] <whitequark> hm, dpkg-checkbuilddeps is satisfied, but configure still fails
[14:12:46] <whitequark> checking for yapps... none
[14:12:51] <whitequark> i have a yapps2 binary
[14:15:39] <whitequark> i also had to install bwidget, libtk-img and tclx. missing dependency?
[15:19:30] -!- sliptonic has joined #linuxcnc-devel
[15:20:56] <sliptonic> Hey everyone, I'm working on a 4th axis surfacing operation for FreeCAD. I'm generating gcode that looks good but when I run it, linuxcnc stops on a particular line with no error. It just stops moving. How can I figure out what's going on?
[15:31:46] <rmu> sliptonic: any message in the console?
[15:35:32] <sliptonic> No. I seen an Emit Interp-run when I start it, but nothing when it stops
[15:36:21] <sliptonic> Linuxcnc/gmoccapy is not frozen. I can stop the job, restart, jog, MDI, everything.
[15:36:36] <sliptonic> It just refuses to run past the line.
[15:37:14] <hazzy-m> sliptonic: what state does it stop in? READING, WAITING, IDLE?
[15:38:34] <sliptonic> I'm not sure. How do I determine state?
[15:45:41] <hazzy-m> sliptonic: you can use the LinucCNC Status tool (available from the Machine menu in Axis, and I think from the settings page in Gmoccapy), or from the command line as linuxcnctop
[15:46:04] <hazzy-m> watch the interp_state value, that might give you a hint were it is hanging
[15:46:33] <hazzy-m> you can also look at motion_type, to see what motion it hangs on
[15:47:06] <skunkworks> pcw_home: the 'WARNING: this firmware has Muxed Encoder v2!' should be fixed after a apt-get update/upgrade?
[15:53:53] <skunkworks> hmm - no.
[15:58:28] <skunkworks> This is for 5i20...
[15:58:55] <skunkworks> I just installed stretch on the K&T... Went very smooth..
[15:59:18] <skunkworks> (and I have a special comp and arduino interface...)
[16:02:16] <pcw_home> needs newer firmware, probably fixed if you fetch bitfile from Mesa
[16:02:51] <pcw_home> that's an _old_ bug
[16:03:08] <pcw_home> maybe 10 years or more
[16:04:37] <skunkworks> heh
[16:05:03] * Tom_L feels skunkworks should be running state of the art firmware
[16:05:04] <skunkworks> I figured. So just get the bit files from mesa and put them (where do they go?)
[16:06:22] <pcw_home> "/lib/firmware/hm2/5i20"
[16:06:54] <hazzy-m> skunkworks: what arduino to HAL interface do you use?
[16:08:46] <skunkworks> sound it
[16:08:51] <skunkworks> found it
[16:09:23] <pcw_home> firmware bug is incorrectly scaled velocity estimate with muxed encoders (a copy/paste error)
[16:09:38] <skunkworks> hazzy-m: https://emergent.unpythonic.net
[16:09:48] <skunkworks> non-realtime but it is just for temp compinsation
[16:10:14] <hazzy-m> skunkworks: Thanks! That is the same one I use
[16:10:37] <hazzy-m> there is also a C based comp one
[16:11:38] <hazzy-m> skunkworks: I cleaned jeff's up a bit and made it installable with pip: https://github.com
[16:11:46] <sliptonic> hazzy-m: interp_state is 2 and motion.motion_type is 1
[16:13:46] <hazzy-m> you can decode those here: https://qtpyvcp.kcjengr.com
[16:13:54] <hazzy-m> so it looks like it hangs while reading ...
[16:13:54] <skunkworks> cool!
[16:15:17] <hazzy-m> usually it finishes reading almost immediately after starting the program, so that seems a little odd
[16:15:18] <skunkworks> pcw_home: I downloaded the support software and the SVST8_4.BIT is dated 09-sep-11
[16:16:24] <skunkworks> pcw_home: the on in firmware is dated 2015
[16:18:16] * hazzy-m uploaded an image: 1551647875778.jpg (288KB) < https://matrix.org >
[16:18:33] <hazzy-m> oops, sorry wrong chan
[16:19:29] <sliptonic> I think it's unrelated to my program. Looks like the spindle-at-speed detection is having trouble.
[16:19:34] <sliptonic> Thanks for the help
[16:20:29] <hazzy-m> sliptonic: Ah, good to hear
[16:25:41] <skunkworks> actually - it is the SV12_2X7i48_72.bit
[16:25:49] <skunkworks> but I don't see it in the zip from mesa
[16:40:30] <pcw_mesa> pretty sure you can use the"IM" versions
[16:50:24] -!- alex_joni has quit [Read error: Connection reset by peer]
[16:55:33] -!- alex_joni has joined #linuxcnc-devel
[16:55:33] -!- mode/#linuxcnc-devel [+v alex_joni] by ChanServ
[17:25:08] <skunkworks> pcw_home: ok - I will try it when I am back in the shop
[18:19:56] -!- andypugh has joined #linuxcnc-devel
[19:18:37] -!- andypugh has quit [Quit: andypugh]
[19:18:58] -!- Tom_itx has joined #linuxcnc-devel
[19:42:16] -!- Tom_itx has quit [Quit: Leaving]
[19:53:35] -!- c-log has quit [Ping timeout: 255 seconds]
[19:56:53] -!- Tom_itx has joined #linuxcnc-devel
[19:57:05] -!- c-log has joined #linuxcnc-devel
[19:57:28] -!- Tom_itx has quit [Client Quit]