Still no go for SS on the 8i20. Can anyone confirm that SS actually works in MK or any of these DExx configs, like has anyone been able to connect a SS remote board? The only hal configuration I needed was a config line of "sserial_port_0=00xxxx". Other than that I see that hm2 has to be brought up with "newinst". I assume there's not much difference being compiled as instcomp rather than legacy?
>From what I understand right now, the SS host is supposed to send a 0xDF and recieve a 0xAA from the 8i20 in return for the handshake. If I could get my scope going and see 11011111 directly on the Tx pin I could verify that the SS host is doing it's job. On Fri, Aug 23, 2019 at 5:21 PM justin White <blazin...@gmail.com> wrote: > The last one I tested was still a no go, tried to get the USB scope > working but having software issues in the new PC. I did yank the 8i20 out > of the mill to make it easier to test. > > I'll try this one and see how it goes > > On Fri, Aug 23, 2019 at 4:59 PM Michael Brown <mib.holotro...@gmail.com> > wrote: > >> So ... Latest and great .. (for)test... >> Everything tested (on all my current MK setups)and working here... :-) >> >> Hope This config gets the SSerial working @your end ..... >> >> >> On Friday, 23 August 2019 17:06:21 UTC+2, Michael Brown wrote: >>> >>> Ok >>> Here: >>> Everything worked execpt the capsensot (tested on my ob-ox router >>> running on a DE0_), so >>> reverted the CapSense pin commit (seems like I have perhaps loaded the >>> pin array backwards) >>> >>> On Friday, 23 August 2019 16:18:41 UTC+2, Michael Brown wrote: >>> >>> OK found the flaw in that commit (leading to currupt io), and was able >>> to fix it. >>> Expect a new bit file in about 2 docker compile times.... :-), 1/2 hour >>> or so... >>> >>> On Friday, 23 August 2019 15:56:59 UTC+2, justin White wrote: >>> >>> lol thanks, I do appreciate it >>> >>> >>> On Fri, Aug 23, 2019 at 8:56 AM Michael Brown <mib.ho...@gmail.com> >>> wrote: >>> >>> Ups Looked like I messed up testing one of my commits: (by copying the >>> wrong .rbf file) >>> And that that commit (the one for configuring CapSense pins) was >>> faulty.... >>> >>> rebasing .. compiling ... and re-testing now .... AArrrghh >>> >>> >>> On Friday, 23 August 2019 13:35:22 UTC+2, Michael Brown wrote: >>> >>> Looked at the manual for the 8i20 you mentioned: >>> http://www.mesanet.com/pdf/motion/8i20man.pdf >>> >>> Page 5 specifies 2 rx and 2 tx channels .... ? >>> >>> >>> On Friday, 23 August 2019 13:16:41 UTC+2, Michael Brown wrote: >>> >>> You forgot the reply all so I repost here: >>> >>> I tried it with the first .rbf you posted and still didn't get it to >>> communicate. I'll try the 2nd one tomorrow. >>> The problem at the moment is that I haven't seen my setup work with a >>> known good SS config and the DE10-Nano config hasn't worked with known good >>> hardware. I can't think of an easy way to test the hardware other than to >>> scope it which I'll do if you can't find the firmware issue easily. >>> >>> >>> I thought Charles Mentioned a working setup above so I looked thru the >>> thread: >>> (Thinking you could test with that DE10_..._DB25 config) >>> REcap: >>> >>> Charles >>> Re: [Machinekit] Re: DE10 Nano suggested development environment? >>> On 7/7/2019 4:29 AM, Michael Brown wrote: >>> > Looking at a 7i76e manual it's differential RS422 while the >>> > example configs suggest at the FPGA level it's a 2 pin RX/TX deal, >>> > is that right? One example shows a TX enable pin, but I don't >>> > think this is implemented on a board like the 7i76e which is all >>> > I'm trying to duplicate. Any insight on this? >>> > >>> > I have no experience with rs422 or rs485, but i guess yes.... >>> RS-422 is always differential. It may be full duplex (which only >>> requires TX and RX) or half duplex (which adds a TX-Enable signal). >>> The 7i76 daughtercard requires two SSERIAL channels, one for the 7i76 >>> itself (for the Field I/O signals), and one which gets exported via >>> the TB3 connector. >>> Both buses are full duplex and do not require a TX-Enable signal. >>> The SSERIAL communication between the FPGA and the 7i76 is via >>> standard digital logic levels. The 7i76 provides an RS-422 >>> transceiver for the SSERIAL bus on TB3. >>> >>> >>> So seems like you are missing the 2'nd SSerial in your pin config / Hw >>> setup ? >>> >>> >>> >>> On Thursday, 22 August 2019 22:36:35 UTC+2, Michael Brown wrote: >>> >>> I just ran a docker compilation and attach that file here.(functionality >>> should be the same as the former file,,,(but just in case) :-) >>> >>> On Thursday, 22 August 2019 21:05:16 UTC+2, Michael Brown wrote: >>> >>> OK copied the new .rbf file, renamed and attached it for testing >>> >>> uartx8:\makeUARTTXs:0:auartx 75.2 (56.5) 102.7 (56.8) 27.5 (0.3) 0.0 >>> (0.0) 0.0 (0.0) 95 (95) 197 (63) 0 (0) 0 0 0 0 0 >>> SRL16E:\fifosrl:0:asr16e 3.7 (0.0) 4.8 (0.0) 1.2 (0.0) 0.0 (0.0) 0.0 >>> (0.0) 0 (0) 16 (0) 0 (0) 0 0 0 0 0 >>> look fine now >>> >>> >>> On Thursday, 22 August 2019 20:52:04 UTC+2, Michael Brown wrote: >>> >>> OK >>> I noticed: >>> uartx8:\makeUARTTXs:0:auartx 25.9 (25.9) 28.7 (28.7) 2.8 (2.8) 0.0 (0.0) 0.0 >>> (0.0) 46 (46) 47 (47) 0 (0) 0 0 0 0 0 >>> SRL16E:\fifosrl:0:asr16e >>> >>> Were Empty, so I'm currently compiling a correction to the uart tx >>> wireing mishap. brb in 12 min or so... >>> >>> On Thursday, 22 August 2019 18:50:12 UTC+2, justin White wrote: >>> >>> I dropped my ADC component on git. This is still the version with the >>> problematic filter, but I figure this would make it easier for my friend or >>> anyone else with interest to fix that portion >>> https://github.com/blazini36/ST_DC1-configs/tree/master/ADC_component >>> >>> On Thursday, August 22, 2019 at 11:04:23 AM UTC-4, justin White wrote: >>> >>> The pin comments in the .vhd were a little messed up due to the changes >>> I was making on board revs, copy/paste only goes so far lol. The actual pin >>> assignments and "function" comments are all correct with the possible >>> exception of the SS pins, can't speak on that until I actually see it work. >>> I sorted the pins out based on convenient PCB layout rather than intuitive >>> config files. You'll have to excuse me if I do something silly on Github, I >>> haven't really hosted any projects before. >>> >>> Definitely getting somewhere with SS, I added your firmware and I can >>> verify from the log file that it now instantiates as "version 43" which is >>> the version that my Mesa boards on my standard LinuxCNC machines. I briefly >>> tested it and I can't verify any communication though, No new 8i20 pins >>> showed up in hal when I connected it to my 8i20. SS is kind of tough to >>> debug on the user end, there's really not much visibility as to what is >>> going on that I'm aware of. It could be a hardware issue yet, I don't have >>> a convenient means of testing SS, right now I take the nano down to my >>> mill, plug it in and hope for the best. Now that I have another nano on >>> hand I can probably get something setup a little better when I get a >>> chance. >>> >>> >>> >>> >>> >>> On Thursday, August 22, 2019 at 7:29:46 AM UTC-4, Michael Brown wrote: >>> >>> OK >>> Besides adding SSerial and your config, I have updated the GPIO pin >>> names from 1-36 to 0-35, >>> I noticed something odd with the pin naming of GPIO_0 in your pin file, >>> so I was unable to update that. >>> Could you explain/clean up those gpio and pin names/numbers ? >>> Is your pin config now final ? >>> >>> Lastly I will push the commits, >>> and create a pr for the SSerial and your config addition after your >>> sucessfull test reports. >>> After sucessfull online build your bitfile will show up in the >>> socfpga-rbf package for both De0 and DE10 board variants. >>> >>> Currently the (now hopefully) whole project is here: >>> https://github.com/the-snowwhite/mksocfpga/tree/sserial-work >>> >>> >>> On Thursday, 22 August 2019 12:52:29 UTC+2, Michael Brown wrote: >>> >>> OK >>> now: >>> MakeSSerials:\GenMakeSSerials:MakeSSerials 649.0 (6.2) 805.6 (6.2) 159.6 >>> (0.0) 3.0 (0.0) 0.0 (0.0) 748 (12) 1129 (0) 0 (0) 40960 5 0 0 0 >>> Entity instance magicially appears in Quartus after full compile. >>> >>> next I'll run the docker compilation and post the bitfiles here >>> >>> On Thursday, 22 August 2019 10:26:57 UTC+2, Michael Brown wrote: >>> >>> Yeah comes to mind the DExx_Cramps projects run on a reduced >>> configuration so only the needed cores are added/included (the one's in the >>> current configs) so... >>> SSerial core needs to be included. >>> I'll do that asap. >>> >>> On Thursday, 22 August 2019 03:53:39 UTC+2, justin White wrote: >>> >>> I threw the new FW on the nano and the stepgens are all working now. >>> Still no SS but I suppose that was to be expected. As PCW said, since the >>> version prints as "0", the SS CPU must be broken. >>> >>> On Wednesday, August 21, 2019 at 3:25:53 PM UTC-4, justin White wrote: >>> >>> Well that makes sense, my SS pins were on GPIO1_00 and GPIO1_01, >>> Stepgens start on GPIO1_02 so it might explain quite a bit. >>> >>> I would have tested it out a bit earlier but I went full nerd yesterday >>> and built a 3900x/5700xt system I've been working on getting running. I got >>> quatus installed and used the config files you attached and I see all of >>> the stepgens are now full. Going to build the .rbf and set it back up to >>> test SS again......hopefully it all just....works lol >>> >>> thanks fellas >>> >>> On Tuesday, August 20, 2019 at 2:06:34 PM UTC-4, Michael Brown wrote: >>> >>> Note: >>> It did really help to have your full quartus project online to play >>> with, that was probaly what immediately triggered my internal >>> analyzer/debugger.... :-) >>> >>> On Tuesday, 20 August 2019 19:54:02 UTC+2, Michael Brown wrote: >>> >>> Valid Files Here: >>> >>> On Tuesday, 20 August 2019 19:50:53 UTC+2, Michael Brown wrote: >>> >>> Ups Sorry sorry sorry ... my BAD .... (Suddently my biain kicked in :-) ) >>> I should have spotted it immediately. >>> Culprit is due to my single experimental (verilog) added capasitive >>> depth/touch sensor core. >>> This is not a part of the "original mesa hm2 vhdl config system, and the >>> pins are hardwired to: >>> GPIO_1 pins 00 + num sense parameter. (if that exact core is enabled in >>> config file) >>> --- >>> Solution is very simple: >>> edit mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps/ >>> atlas_st_fpga_soc_dc1f_ss.sv >>> --> parameter Capsense = 0; >>> >>> I have tested with: >>> (StepGenTag, x"02", ClockLowTag, x"06", >>> StepGenRateAddr&PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >>> >>> and all >>> SRL16E:\steptable:1:asr16e 4.2 (0.0) 8.5 (0.0) 4.3 (0.0) 0.0 (0.0) 0.0 >>> (0.0) 5 (0) 17 (0) 0 (0) 0 0 0 0 0 >>> entities show up populated. >>> :-) >>> once again excuse for my temporary brain paralysys.. >>> ... >>> >>> On Tuesday, 20 August 2019 16:30:50 UTC+2, Charles Steinkuehler wrote: >>> >>> Dig through the synthesis log (*.map.rpt) a bit and look for warnings >>> that indicate undriven nets. Sadly, most tool chains consider >>> undriven signals a warning vs. an error, so they'll happily optimize >>> away huge chunks of your design. A typical warning would look >>> something like: >>> >>> Warning (10541): VHDL Signal Declaration warning at >>> HD_Core_CycloneV_pipen1b.vhd(45): used implicit default value for >>> signal "clk250_out" because signal was never assigned a value or an >>> explicit default value. Use of implicit default value may introduce >>> unintended design optimizations. >>> >>> In vim, I use the regex: ^Warning.*$ which highlights the whole line >>> (if you're in GUI mode). >>> >>> Note you will see lots of other warnings, most of which are probably >>> OK. In particular, the ever present: >>> >>> Warning (10036): Verilog HDL or VHDL warning at >>> HD_Core_CycloneV.vhd(471): object "HDMI_clk" assigned a value but >>> never read >>> >>> ...is (usually) perfectly OK, it's similar to an unused variable in >>> "C". This _might_ be an actual error (if the signal was supposed to >>> go somewhere) but is typically OK. >>> >>> On 8/20/2019 9:09 AM, justin White wrote: >>> > Thanks for the advice Charles. Actually I use this project: >>> > >>> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE10_Nano_FB_Cramps >>> > >>> > Michael explained it has more functionallity than the DB25 project, so >>> I've >>> > never tried the DB25. >>> > >>> > Not really up on my git stuff, I forked master and slapped my config >>> files >>> > in, like I said these are modifications of the "3x24_cap_enc" config. >>> > https://github.com/blazini36/mksocfpga >>> > >>> > The pin assignments are so different from anything else I can't >>> imagine >>> > it's looking at another pinfile, it's likely I just didn't modify >>> something >>> > I probably should have. I'll try to look into your suggestions a bit >>> later. >>> > >>> > >>> > On Tuesday, August 20, 2019 at 9:41:57 AM UTC-4, Charles Steinkuehler >>> wrote: >>> >> >>> >> It sounds like the synthesis tools are optimizing away the stepgen >>> >> logic, almost certainly because of an issue with signal connectivity >>> >> to the top level I/O pins. The actual step accumulator is still >>> >> generated because it's value gets read back via the register >>> >> interface, but the steptables are only needed to generate the output >>> >> signals so they're getting optimized away. >>> >> >>> >> Is your project checked into github somewhere I can grab it? I can >>> >> try building in the desktop Quartus tools and see what's wrong. >>> >> >>> >> Otherwise, double-check the pin assignments the top-level I/O port >>> >> definitions, and make sure the physical I/O pins are properly >>> >> connected to the hm2 instance. >>> >> >>> >> I took a quick look at the project I think you're using: >>> >> >>> >> >>> >> >>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/ >>> >> >>> >> ...and the top-level stuff looks OK at first glance. The important >>> >> part is the use of the correct PIN_<config> library, which gets >>> called >>> >> out here: >>> >> >>> >> >>> >> >>> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/DE10_Nano_SoC_FB_DB25/hostmot2_cfg.vhd.in#L74 >>> >> >>> >> Make sure in your working copy the hostmot2_cfg.vhd file is getting >>> >> generated with the correct name in the "use" line, and make sure the >>> >> pin file you're including in the project has proper values for >>> IOWidth >>> >> and IOPorts. >>> >> >>> >> You can dig through the first part of the compile log messages to >>> >> verify the correct PIN file is _really_ getting analyzed and not some >>> >> other file. >>> >> >>> >> I'm also not sure how mixing the system verilog config files with >>> VHDL >>> >> packages works (I know just enough Verilog to generally be able to >>> >> transcode it to VHDL). If there's any problems with that, Michael B. >>> >> will have to comment. >>> >> >>> >> On 8/20/2019 8:04 AM, justin White wrote: >>> >>> I deleted my mksocfpga directory and re-pulled it and I get the same >>> >>> results after building the .rbf. >>> >>> >>> >>> Still not quite sure what's going on, though I did catch something >>> in >>> >>> Quartus. Using "0A" for stepgens in the pinfile creates 10 >>> stepgens, >>> >> but >>> >>> only the first 4 seem to be complete. #4 (the 5th stepgen) when >>> expanded >>> >>> shows blank resources for "SRL16E:\steptable:0:asr16e", but does >>> show >>> >>> resources for "SRL16E:\steptable:1:asr16e". On every stepgen after >>> they >>> >> are >>> >>> both blank which looks like it mimics exactly the problem I'm >>> having. If >>> >> "steptable:1" >>> >>> relates to the dir pin and "steptable:0" relates to the step pin, it >>> >>> explains why I have a working direction pin on #4 but no step pin, >>> and >>> >> #5 >>> >>> doesn't work at all. In this case I'd assume no later stepgens would >>> >> work. >>> >>> >>> >>> I'm not really sure how Quartus works with the configs. I'm just >>> >> dropping >>> >>> the pinfile I made into the >>> >>> '../mksocfpga/HW/hm2/config/DExx_Nano_xxx_Cramps' directory and >>> renaming >>> >>> the "atlas_3x24_cap_enc.sv" to match my pinfile, which is what I do >>> >> with >>> >>> the mksocfpga docker build. I don't specify a pinfile or anything >>> when >>> >>> running the analysis in Quartus, yet it does seem to catch the >>> changes >>> >> I've >>> >>> made to that specific pinfile even though I don't specify anything >>> in >>> >>> Quartus, I just load the "DE10_Nano_FB_Cramps.qpf" file. >>> >>> >>> >>> Pics, QP1 shows all 10 stepgens, QP2 shows the difference between >>> the >>> >>> working #3 stepgen (0-3 all look the same) and #4 and #5 where the >>> >> problem >>> >>> starts. "combinational ALUTS" and every feild after is blank. >>> >>> >>> >>> [image: QP1.png] >>> >>> >>> >>> [image: QP2.png] >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Monday, August 19, 2019 at 5:00:11 PM UTC-4, Michael Brown wrote: >>> >>>> >>> >>>> Thanx for the clairifying Charles, I doublechecked tha line and it >>> >> reads: >>> >>>> (StepGenTag, x"02", ClockLowTag, x"06", >>> >>>> StepGenRateAddr&PadT, StepGenNumRegs, x"00", >>> >> StepGenMPBitMask), >>> >>>> >>> >>>> So that should be ok... >>> >>>> >>> >>>> On Monday, 19 August 2019 22:37:42 UTC+2, Charles Steinkuehler >>> wrote: >>> >>>>> >>> >>>>> Actually, the NumInstances field of the ModuleRecord is defined as >>> an >>> >>>>> 8 bit std_logic_vector: >>> >>>>> >>> >>>>> >>> >>>>> >>> >> >>> https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/IDROMConst.vhd#L839 >>> >>>>> >>> >>>>> In VHDL, it should throw an error if you use 06 for this value >>> (VHDL >>> >>>>> won't convert an integer value into a std_logic_vector without >>> some >>> >>>>> sort of type conversion). >>> >>>>> >>> >>>>> If you meant that you are using x"06" (an 8-bit hexadecimal >>> value), >>> >>>>> that should work fine, but you will only get 6 stepgens instead of >>> the >>> >>>>> 10 you'd get with x"0A". >>> >>>>> >>> >>>>> On 8/19/2019 3:19 PM, Michael Brown wrote: >>> >>>>>> No changing numinst should work just fine >>> >>>>>> >>> >>>>>> On Monday, 19 August 2019 18:05:28 UTC+2, justin White wrote: >>> >>>>>>> >>> >>>>>>> One thing I noticed, I recall seeing this the first time I >>> started >>> >>>>> messing >>> >>>>>>> with the .vhd's. All of the pinfiles in the DExx_Nano_xxx_Cramps >>> >>>>> config use >>> >>>>>>> this line for stepgens >>> >>>>>>> >>> >>>>>>> (StepGenTag, x"02", ClockLowTag, x"0A", >>> >>>>> StepGenRateAddr& >>> >>>>>>> PadT, StepGenNumRegs, x"00", StepGenMPBitMask), >>> >>>>>>> >>> >>>>>>> The NumInst being "0A" looked a little strange to me so I >>> changed it >>> >>>>> to >>> >>>>>>> the actual number (06) for every pinfile I've been working with. >>> >> Could >>> >>>>> that >>> >>>>>>> be causing an issue? >>> >>>>>>> >>> >>>>>>> On Monday, August 19, 2019 at 11:33:29 AM UTC-4, justin White >>> wrote: >>> >>>>>>>> >>> >>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >>> >>>>>>>>>> hm2_soc_ol config line here: >>> >>>>>>>>>> < >>> >>>>> >>> >> >>> https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Mibrap-X_hm3_fdm-soc/fdm/config/motion.py#L15> >>> >>> >> >>> >>>>> >>> >>>>>>>>>> Have you tried with: >>> >>>>>>>>>> num_stepgens=6 in the hm2_soc_ol config line ? >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>> Yes, my config line is: >>> >>>>>>>> [HOSTMOT2] >>> >>>>>>>> DRIVER=hm2_soc_ol >>> >>>>>>>> BOARD=5i25 >>> >>>>>>>> CONFIG="num_encoders=6 num_stepgens=6" "enable_adc=1" >>> >>>>>>>> DEVNAME=hm2-socfpga0 already_programmed=1 >>> >>>>>>>> >>> >>>>>>>> If the stepgens=6 wasn't there hm2 wouldn't instantiate them in >>> >> HAL. >>> >>>>> They >>> >>>>>>>> are actually completely visible and HAL seems to think they're >>> >>>>> working. I >>> >>>>>>>> dug up one of my first test hal files and #4 did in fact work >>> with >>> >>>>> that but >>> >>>>>>>> I had much less else going on. >>> >>>>>>>> >>> >>>>>>>> I'm not terribly familiar with Quartus. I usually just do as in >>> the >>> >>>>>>>> readme https://github.com/the-snowwhite/mksocfpga to build the >>> >>>>> firmware. >>> >>>>>>>> I did have an issue before where it was building firmware that >>> >>>>> wouldn't >>> >>>>>>>> boot, deleting mksocfpga and pulling it again fixed that. That >>> may >>> >>>>> even >>> >>>>>>>> have had something to do with trying to open the project >>> >> previously. >>> >>>>> Ill >>> >>>>>>>> try re-pulling it and see what happens. >>> >>>>>>>> >>> >>>>>>>> I ran the analysis in in QP and this is what I'm seeing with >>> the >>> >>>>>>>> stepgens: >>> >>>>>>>> >>> >>>>>>>> [image: QP.png] >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> On Monday, August 19, 2019 at 7:46:58 AM UTC-4, Michael Brown >>> >> wrote: >>> >>>>>>>>> >>> >>>>>>>>> Quartus Update: >>> >>>>>>>>> After compiling (the default DE10_Nano_FB_Cramps project) >>> Notice >>> >>>>> that >>> >>>>>>>>> all 9 (0-8) stepgens instansiated in the pin file have a (not >>> >> null) >>> >>>>> sized >>> >>>>>>>>> SRL16E:\steptable:0:asr16e instance: >>> >>>>>>>>> >>> >>>>>>>>> [image: >>> Quartus_DE10_Nano_FB_Default_Num-Stepgens_Compiled.png] >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> On Monday, 19 August 2019 13:24:22 UTC+2, Michael Brown wrote: >>> >>>>>>>>>> >>> >>>>>>>>>> I have an older config that has worked with 8 stepgens: >>> >>>>>>>>>> hm2_soc_ol config line here: >>> >>>>>>>>>> < >>> >>>>> >>> >> >>> >>> ... >> >> -- >> website: http://www.machinekit.io blog: http://blog.machinekit.io >> github: https://github.com/machinekit >> --- >> You received this message because you are subscribed to the Google Groups >> "Machinekit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to machinekit+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/machinekit/27f6ecd2-1bd9-43db-a479-2c4c926541a1%40googlegroups.com >> <https://groups.google.com/d/msgid/machinekit/27f6ecd2-1bd9-43db-a479-2c4c926541a1%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/CA%2BQ02MP-HLWRU4gMcKh47dgQ7cjibqCuLyzM-%3D3dkCewf3hzwQ%40mail.gmail.com.
