Yes that tag's fine leave it as it is. (this tag gets the adc support compiled into the .rbf) Since the adc is onboard the adc pins are wired internally (not via gpio's) so there are no pin settings in that file.
All you need to do is ensure you load/instansiate the hostmot2_ol driver with the enable_adc=1 parameter included. then the adc pins will show up on the hm2_5i25.0 component (ie:hm2_5i25.0.nano_soc_adc.ch.0.out etc ) You can take a look at my python based Prusa-i3 config here: https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/prusa-i3_dev.ini#L4 https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/cramps.py#L85 BTW: remember that the DExx ADC's max out at 4 Volt... On Friday, 28 June 2019 02:59:20 UTC+2, justin White wrote: > > What is the method for using the ADC? I wasn't very concerned about the > ADC on the first go so I didn't bother with it at all really. I'm going to > have to whip up a new .vhd and .rbf for another revision of my board and > I'm actually using it. > > I have the "pintype" copied over from the original .vhd I used as a > template: > (NANOADCTag, x"00", ClockLowTag, x"08", NANOADCAddr&PadT, > NANOADCNumRegs, x"00", NANOADCBitMask), > > > Couldn't find an example of how to add it to the pin description section > of the PIN.vhd (if that's necessary) or how to instantiate it in the > ini/hal file. > > > On Friday, June 21, 2019 at 5:51:53 PM UTC-4, justin White wrote: >> >> Where did you find the (no-fw-load.ini)example where that line was Not >>> commeted out ? >> >> Like I said in the first post, I started with that image. I couldn't >> mount the original image to check the .ini but I do see that the Git repo >> version is commented out. Maybe I uncommented it, not sure how I'd miss >> uncommenting one line and not commenting the other though.........but it >> happens. >> >> On Friday, June 21, 2019 at 6:27:55 AM UTC-4, Michael Brown wrote: >>> >>> I dont know how the discussion got off-list, so here's a paste: >>> >>> On Thu, Jun 20, 2019 at 6:10 PM Michael Brown write: >>> Ups Sorry for providing too much information, let me clarify: >>> You can use either: >>> the no load ini method (requires you setup u-boot variables to program >>> the fpga on boot) >>> OR >>> using a .dtbo file (device tree fragment that programs the fpga) you >>> specify machinekit(the hm2_soc_ol driver) to load on startup >>> But never both...! (as this will give problems with the uio device) >>> >>> So bottom line is If you choose to have the display option on th >>> DE10_Nano hdmi port: forget the .dtbo related stuff. >>> --- >>> ok ? >>> >>> >>> That's actually good to know. I don't think the framebuffer or at least >>>> the HDMI port will be necessary after I get the hardware sorted out. Do >>>> you >>>> know if VNC require an actual framebuffer? If I can access the desktop >>>> through VNC I would probably reconfigure without it when I'm done. >>>> >>> No I don't know about vnc. >>> >>> >>>> Now that I look at it, the reason I messed with a .dtbo file in the >>>> first place is because the .ini i modified contained the >>>> "CONFIG=xxx3x24.dtbo" line and that was throwing LinuxCNC errors until I >>>> renamed it. It's a bit confusing because the example FB .ini's still >>>> reference a .dtbo file is compiled from a .dts file that points to a non >>>> FB >>>> .rbf. >>>> I just commented out that config line in the .ini and MK still seems to >>>> load up just fine, which is probably what I should have just done in the >>>> beginning. Should this line be removed, or commented out from the provided >>>> example MK no-load .ini's? >>> >>> >>> Where did you find the (no-fw-load.ini)example where that line was Not >>> commeted out ? >>> >>> >>> On Thursday, 20 June 2019 23:37:42 UTC+2, justin White wrote: >>>> >>>> However can you explain to me why you think you need the .dtbo ? >>>>> >>>> >>>> Well actually it's because you said: >>>> >>>> The .dtbo file is compiled from the (renamed/edited).dts file via the >>>>> dtc (device tree compiler) tool. >>>> >>>> So if you just renamed the .dtbo file it will stil configure the fpga >>>>> with the "old" .rbf file. >>>> >>>> >>>> the "no-load.ini" (Machinekit does not load firmware on startup) >>>>> method masks this mistake as it requires you load your firmware via >>>>> u-boot >>>>> before the linux kernel starts up (to not get a blank screen or worse if >>>>> mackinekit re-loads the firmware). >>>> >>>> >>>> So I thought you were saying that just renaming the .dts (plus >>>> changing the firmware tag) and .dtbo files was not sufficient. It does >>>> work >>>> but I am using the "no-load.ini" right now. I have to make some changes to >>>> the board and the pinouts are changing some as well so since I have to do >>>> this again I may as well figure out how to do it right. Are you suggesting >>>> that I don't need to worry about the .dtbo? >>>> >>>> On Thursday, June 20, 2019 at 4:12:49 AM UTC-4, Michael Brown wrote: >>>>> >>>>> You can just download the dtc compiler .deb from debian buster then >>>>> you do not have to use the -@ switch. >>>>> However can you explain to me why you think you need the .dtbo ? >>>>> >>>>> On Thursday, 20 June 2019 04:08:21 UTC+2, justin White wrote: >>>>>> >>>>>> Had to compile a newer version of dtc on the desktop, apparently the >>>>>> -@ switch isn't available until later versions. I get a .dtbo output >>>>>> but..... >>>>>> >>>>>> $ dtc -@ -I dts -O dtb -o DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dtbo >>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts >>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:8.29-27.19: Warning >>>>>> (unit_address_vs_reg): /fragment@0/__overlay__: node has a reg or ranges >>>>>> property, but no unit name >>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:18.59-26.27: Warning >>>>>> (unit_address_format): /fragment@0/__overlay__/hm2-socfpga0@0x40000: >>>>>> unit >>>>>> name should not have leading "0x" >>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:4.20-28.11: Warning >>>>>> (avoid_unnecessary_addr_size): /fragment@0: unnecessary >>>>>> #address-cells/#size-cells without "ranges" or child "reg" property >>>>>> DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:21.33-58: Warning >>>>>> (interrupts_property): >>>>>> /fragment@0/__overlay__/hm2-socfpga0@0x40000:interrupt-parent: Bad >>>>>> phandle >>>>>> >>>>>> >>>>>> Anything to worry about? >>>>>> >>>>> >>>>> >>>>>> >>>>>> On Wednesday, June 19, 2019 at 8:26:04 PM UTC-4, Charles Steinkuehler >>>>>> wrote: >>>>>>> >>>>>>> If you want to create an overlay you need to use the -@ command line >>>>>>> switch with dtc. >>>>>>> >>>>>>> On 6/19/2019 7:02 PM, justin White wrote: >>>>>>> > Any instructions on compiling the .dtbo? Trying to take some notes >>>>>>> on what >>>>>>> > I had to do to get this going and figured I'd try to do this the >>>>>>> right way >>>>>>> > but it keeps choking on the following error: >>>>>>> > >>>>>>> > machinekit@mksocfpga-nano-soc:/lib/firmware/socfpga/dtbo$ dtc -I >>>>>>> dts -O dtb >>>>>>> > -o DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dtbo >>>>>>> > DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts >>>>>>> > Error: DE0_Nano_SoC_Cramps.st_fpga_soc_dc1.dts:1.12-18 syntax >>>>>>> error >>>>>>> > FATAL ERROR: Unable to parse input tree >>>>>>> > >>>>>>> > Same thing trying to compile it on my desktop and the DE10. Looks >>>>>>> like it's >>>>>>> > choking on "plugin" in the .dts file? >>>>>>> > >>>>>>> > >>>>>>> > On Sunday, June 16, 2019 at 10:14:04 PM UTC-4, justin White wrote: >>>>>>> >> >>>>>>> >> Did you mean compiled ? >>>>>>> >>> >>>>>>> >> No, I mean copied >>>>>>> >> >>>>>>> >> The .dtbo file is compiled from the (renamed/edited).dts file via >>>>>>> the dtc >>>>>>> >>> (device tree compiler) tool. >>>>>>> >>> So if you just renamed the .dtbo file it will stil configure the >>>>>>> fpga >>>>>>> >>> with the "old" .rbf file. >>>>>>> >>> >>>>>>> >> I couldn't find the .dtbo or .dts files so I figured I'd try >>>>>>> this. No >>>>>>> >> bullshit, it works. All of the I/O (encoders,stepgens) is where >>>>>>> it belongs. >>>>>>> >> Though if I do find the right files I'll move them. >>>>>>> >> >>>>>>> >>> the "no-load.ini" (Machinekit does not load firmware on startup) >>>>>>> method >>>>>>> >>> masks this mistake as it requires you load your firmware via >>>>>>> u-boot before >>>>>>> >>> the linux kernel starts up (to not get a blank screen or worse >>>>>>> if >>>>>>> >>> mackinekit re-loads the firmware). >>>>>>> >>> >>>>>>> >> Maybe that explains it :) >>>>>>> >> >>>>>>> >> >>>>>>> >>> you need to change the u-boot variable bitimage: >>>>>>> >> >>>>>>> >> (assuming you copied you new (st_fpga_soc_dc1.rbf ?) bitfile to >>>>>>> >> /lib/firmware/socfpga) you can do: >>>>>>> >> sudo fw_setenv bitimage >>>>>>> '/lib/firmware/socfpga/st_fpga_soc_dc1.rbf' >>>>>>> >> sudo reboot now >>>>>>> >> On the soc >>>>>>> >> and then watch for the flashing led :-) >>>>>>> >> >>>>>>> >> >>>>>>> >> That's what I did, the LED flashes and I've been using it since >>>>>>> my last >>>>>>> >> post. Like you said, maybe I got away with it because of the >>>>>>> "no-load" >>>>>>> >> >>>>>>> >> On Sunday, June 16, 2019 at 9:27:41 PM UTC-4, Michael Brown >>>>>>> wrote: >>>>>>> >>> >>>>>>> >>> I had some errors starting MK. I copied the 3x24.dtbo >>>>>>> >>>> >>>>>>> >>> Did you mean compiled ? >>>>>>> >>> >>>>>>> >>> >>>>>>> >>>> and dts and renamed it to match my config >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> The .dtbo file is compiled from the (renamed/edited).dts file >>>>>>> via the dtc >>>>>>> >>> (device tree compiler) tool. >>>>>>> >>> So if you just renamed the .dtbo file it will stil configure the >>>>>>> fpga >>>>>>> >>> with the "old" .rbf file. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>>> and changed the firmware line in the dts to point to the new >>>>>>> firmware. >>>>>>> >>>> Then all it seems I had to do was modify the no-load.ini >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> the "no-load.ini" (Machinekit does not load firmware on startup) >>>>>>> method >>>>>>> >>> masks this mistake as it requires you load your firmware via >>>>>>> u-boot before >>>>>>> >>> the linux kernel starts up (to not get a blank screen or worse >>>>>>> if >>>>>>> >>> mackinekit re-loads the firmware). >>>>>>> >>> >>>>>>> >>> >>>>>>> >>>> to point to my firmware and instantiate the proper number of >>>>>>> stepgens >>>>>>> >>>> and encoders. >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> --> no >>>>>>> >>> >>>>>>> >>>> Looks like a good start until I get a chance to write a proper >>>>>>> hal file >>>>>>> >>>> - >>>>>>> >>>> >>>>>>> >>> you need to change the u-boot variable bitimage: >>>>>>> >>> (assuming you copied you new (st_fpga_soc_dc1.rbf ?) bitfile to >>>>>>> >>> /lib/firmware/socfpga) you can do: >>>>>>> >>> >>>>>>> >>> sudo fw_setenv bitimage >>>>>>> '/lib/firmware/socfpga/st_fpga_soc_dc1.rbf' >>>>>>> >>> sudo reboot now >>>>>>> >>> On the soc >>>>>>> >>> and then watch for the flashing led :-) >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On Sunday, 16 June 2019 22:24:41 UTC+2, justin White wrote: >>>>>>> >>>> >>>>>>> >>>> I renamed the files you mentioned and got an output, not sure >>>>>>> if the >>>>>>> >>>> below error means anything: >>>>>>> >>>> >>>>>>> builder@300dd4c4fceb:/work/HW/QuartusProjects/DE10_Nano_FB_Cramps$ >>>>>>> >>>> Inconsistency detected by ld.so: dl-close.c: 762: _dl_close: >>>>>>> Assertion >>>>>>> >>>> `map->l_init_called' failed! >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> I had some errors starting MK. I copied the 3x24.dtbo and dts >>>>>>> and >>>>>>> >>>> renamed it to match my config and changed the firmware line in >>>>>>> the dts to >>>>>>> >>>> point to the new firmware. Then all it seems I had to do was >>>>>>> modify the >>>>>>> >>>> no-load.ini to point to my firmware and instantiate the proper >>>>>>> number of >>>>>>> >>>> stepgens and encoders. Looks like a good start until I get a >>>>>>> chance to >>>>>>> >>>> write a proper hal file >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> On Sunday, June 16, 2019 at 12:53:10 PM UTC-4, Michael Brown >>>>>>> wrote: >>>>>>> >>>>> >>>>>>> >>>>> Looking at your errorlog this is what sticks out for me: >>>>>>> >>>>> >>>>>>> >>>>> Warning (12019): Can't analyze file -- file >>>>>>> >>>>> ../../hm2/config/DExx_Nano_xxx_Cramps/atlas_st_fpga_soc_dc1.sv >>>>>>> is >>>>>>> >>>>> missing >>>>>>> >>>>> >>>>>>> >>>>> So you can create a copy of a suitable atlas_3x24 .....sv >>>>>>> named >>>>>>> >>>>> atlas_st_fpga_soc_dc1.sv >>>>>>> >>>>> < >>>>>>> http://www.google.com/url?q=http%3A%2F%2Fatlas_st_fpga_soc_dc1.sv&sa=D&sntz=1&usg=AFQjCNFaXzIhSaX4akk6lI9iwZh_k2ltVA> >>>>>>> >>>>>>> >>>>>>> >>>>> (With your naming convention), >>>>>>> >>>>> and customize it if you fell so inclined..... then it should >>>>>>> build. >>>>>>> >>>>> Best Wishes >>>>>>> >>>>> Michael Brown >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> On Sunday, 16 June 2019 18:36:03 UTC+2, Michael Brown wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> Please notice that only the header and extension is different >>>>>>> in the >>>>>>> >>>>>> two added files: >>>>>>> >>>>>> >>>>>>> >>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/PIN_3x24_cap_enc_dbspi.vhd >>>>>>> >>>>>> HW/hm2/config/DExx_Nano_xxx_Cramps/ >>>>>>> atlas_3x24_cap_enc_dbspi.sv >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> On Sunday, 16 June 2019 18:31:31 UTC+2, Michael Brown wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> To add a new config you have to add 2 new files like in this >>>>>>> pending >>>>>>> >>>>>>> commit Charles yet has not had time to look at: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://github.com/machinekit/mksocfpga/pull/106/commits/cf035069c539dda57131a2190499f204f9f5412f >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Note that I have tried to build a cosistant (by function) >>>>>>> file naming >>>>>>> >>>>>>> convention as the names of the 2 files reflect in the >>>>>>> bitfiles you get out >>>>>>> >>>>>>> at the other end. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sunday, 16 June 2019 14:25:23 UTC+2, Charles Steinkuehler >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> It looks like the pertinent error is: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Error (10161): Verilog HDL error at >>>>>>> DE10_Nano_FB_Cramps.sv(132): >>>>>>> >>>>>>>> object "boardtype" is not declared. Verify the object name >>>>>>> is >>>>>>> >>>>>>>> correct. >>>>>>> >>>>>>>> If the name is correct, declare the object. File: >>>>>>> >>>>>>>> >>>>>>> /work/HW/QuartusProjects/DE10_Nano_FB_Cramps/DE10_Nano_FB_Cramps.sv >>>>>>> >>>>>>>> Line: 132 >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> I'm not quite sure what's going wrong, I haven't really >>>>>>> worked with >>>>>>> >>>>>>>> Michael's new System Verilog top-level design. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> On 6/15/2019 8:31 PM, justin White wrote: >>>>>>> >>>>>>>>> Trying to build the bitfile, I'm sure I'm doing something >>>>>>> wrong. >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> I modified the "PIN_3x24_cap_enc.vhd" pinfile posted >>>>>>> earlier to >>>>>>> >>>>>>>> suit my >>>>>>> >>>>>>>>> board and tried to build it via the readme based on the >>>>>>> >>>>>>>>> "DE10_Nano_FB_Cramps" project. I'm sure I'm missing a step >>>>>>> here. >>>>>>> >>>>>>>> Print and >>>>>>> >>>>>>>>> .vhd attached. >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> On Saturday, June 15, 2019 at 2:55:03 PM UTC-4, justin >>>>>>> White >>>>>>> >>>>>>>> wrote: >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> No smoke yet. >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> [image: Photo Jun 15, 2 47 40 PM.jpg] >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> On Tuesday, June 11, 2019 at 10:41:16 PM UTC-4, justin >>>>>>> White >>>>>>> >>>>>>>> wrote: >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> Well once I get a PCB all assembled I'll have to go back >>>>>>> through >>>>>>> >>>>>>>> this >>>>>>> >>>>>>>>>>> thread and figure out how to get the FPGA all set up >>>>>>> lol. The >>>>>>> >>>>>>>> Arduino >>>>>>> >>>>>>>>>>> connector on the DE10 kind of irk me, they are extended >>>>>>> height >>>>>>> >>>>>>>> an 4 or 5mm >>>>>>> >>>>>>>>>>> taller than the 2x20 headers so either tall pin sockets >>>>>>> have to >>>>>>> >>>>>>>> be sourced >>>>>>> >>>>>>>>>>> or I've thought about just desoldering the Arduino >>>>>>> connectors >>>>>>> >>>>>>>> from the DE10. >>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> On Tuesday, June 11, 2019 at 1:56:27 AM UTC-4, Bas de >>>>>>> Bruijn >>>>>>> >>>>>>>> wrote: >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> On 11 Jun 2019, at 01:25, justin White < >>>>>>> blaz...@gmail.com> >>>>>>> >>>>>>>> wrote: >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Possibly, >>>>>>> >>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> Need to do some testing once I get the first rev >>>>>>> assembled. >>>>>>> >>>>>>>> This >>>>>>> >>>>>>>>>>>> Particular board is probably a bit too expensive to >>>>>>> make for >>>>>>> >>>>>>>> the open >>>>>>> >>>>>>>>>>>> source world to want, and the I/O arrangement is >>>>>>> somewhat >>>>>>> >>>>>>>> specific to my >>>>>>> >>>>>>>>>>>> needs. That many Phoenix Contact blocks gets pretty >>>>>>> expensive. >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> I would be interested, keep me updated! >>>>>>> >>>>>>>>>>>> I think machinekit can do with some additional hardware >>>>>>> between >>>>>>> >>>>>>>>>>>> controllers and wires. >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> but imo cheap is a nice to have, function and quality >>>>>>> come >>>>>>> >>>>>>>> first. Think >>>>>>> >>>>>>>>>>>> about how something industrial gets wired. Then you >>>>>>> need some >>>>>>> >>>>>>>> contact >>>>>>> >>>>>>>>>>>> blocks to easily connect wires. In the total a more >>>>>>> expensive >>>>>>> >>>>>>>> part here >>>>>>> >>>>>>>>>>>> will give you an edge somewhere else (manual labor). >>>>>>> And indeed >>>>>>> >>>>>>>> when you’re >>>>>>> >>>>>>>>>>>> a diy-er labor does not come into the equation. >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>> I'll probably drop some OS version into the wild once >>>>>>> I get it >>>>>>> >>>>>>>> sorted, >>>>>>> >>>>>>>>>>>> with a more general I/O layout. This board is setup >>>>>>> with 6 >>>>>>> >>>>>>>> differential (or >>>>>>> >>>>>>>>>>>> single ended) encoder inputs, 6 differential stepgen >>>>>>> outputs, >>>>>>> >>>>>>>> 16 5v-30v >>>>>>> >>>>>>>>>>>> inputs, 24 field voltage outputs up to 500ma, 2 >>>>>>> opto-mosfet >>>>>>> >>>>>>>> outputs @2A >>>>>>> >>>>>>>>>>>> snubbed. Has a 5A 5v DC-DC regulator that will accept >>>>>>> up to >>>>>>> >>>>>>>> 42VDC, power >>>>>>> >>>>>>>>>>>> the DE10-nano through GPIO and output the spare 5v up >>>>>>> to 3A. My >>>>>>> >>>>>>>> method of >>>>>>> >>>>>>>>>>>> stepgen outputs and GP inputs needs some testing. >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> -- >>>>>>> >>>>>>>> Charles Steinkuehler >>>>>>> >>>>>>>> cha...@steinkuehler.net >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> > >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Charles Steinkuehler >>>>>>> cha...@steinkuehler.net >>>>>>> >>>>>> -- 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. Visit this group at https://groups.google.com/group/machinekit. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/a3e48ee1-5a1c-4122-9cac-ef61937b8c62%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
