Its easy to convert float to u32 and visa versa in a handmade hal component. For the printer temp sensor config I created the: hal_temp_atlas.py <https://github.com/machinekit/machinekit-hal/blob/master/src/hal/user_comps/hal_temp_atlas.py> user component variant instansiated here: https://github.com/the-snowwhite/Hm2-soc_FDM/blob/master/Cramps/PY/Prusa-i3_Dev/cramps.py#L25
I ended up with wirering the Cramps adc reference to the 3.3 volt power line, and then connecting adc channel 8 to the 3.3 V rail used as a reference in that component. In a hal comp component you can just typecast between u32 and float like in this comp: Example is float to u32 <https://github.com/the-snowwhite/Hm2-soc_FDM/blob/trinamic-spi/projects/Comp/trinamic_dbspi.comp#L150> On Saturday, 29 June 2019 03:11:03 UTC+2, justin White wrote: > > I figured that was pretty much the case, I just haven't seen the > enable_adc parameter used. I added the parameter and the nano_soc_adc pins > exposed in HAL as expected. > > I suppose I didn't fully understand what to expect from the values the > pins expose, I see an integer that looks to be 32bits wide (U32 pin) with a > variation of 12bits if that makes any sense. With an input of 0v to the > 5v_ref there is a change of 4096 which explains the 4v max. Slightly > difficult to deal with with pure HAL. Passing the outputs through an offset > then scale component is what I would do but since it's a U32 pin it'll > require a U32 to float conversion first. I'm sure there's a more elegant > way to handle the values but unless there's a more suitable hal component > that's probably what I'd do. > > I didn't realize the value would max out at 4.095v but looking at the ADC > chip's datasheet it does explain that. Not a huge deal as they can handle > over 5v electrically. My 2nd board takes runs resistor dividers to accept > 0-10v on 4 of the ADC pins. > > On Friday, June 28, 2019 at 6:24:04 PM UTC-4, Michael Brown wrote: >> >> 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 < >>>>>>>>> [email protected]> >>>>>>>>> >>>>>>>> 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 >>>>>>>>> >>>>>>>> [email protected] >>>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Charles Steinkuehler >>>>>>>>> [email protected] >>>>>>>>> >>>>>>>> -- 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 [email protected]. 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/5ee1ae8b-6f9c-43cb-87b3-8e3001a379bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
