Re: [Machinekit] Re: M-Code errors

2017-08-30 Thread Pranav Pandey 

>
> Link please (no attachment, I won't open it) to exact file, either on 
> Machinekit repository or your own github fork
>

Apologies. I am new to these. Here is a link:

https://raw.githubusercontent.com/pranav451/Test-file/master/Test9

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: M-Code errors

2017-08-30 Thread Bas de Bruijn 


On 31 Aug 2017, at 08:04, Pranav Pandey  wrote:

>> Which configuration do you use? Please provide a link to the file in your 
>> own or the machinekit repo so we can see.
> 
> CRAMPS Configuration.  

Link please (no attachment, I won't open it) to exact file, either on 
Machinekit repository or your own github fork

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Reading current/torque from Mesa motion cards

2017-08-30 Thread Bas de Bruijn 

> On 30 Aug 2017, at 23:59, Michael Brown  wrote:
> 
> Yes (ADC functionality is not added to the bitfiles from that Quartus 
> project:  
> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE0_Nano_SoC_DB25)
> 
> Initially only the recent added 3 new .rbf bitfiles, generated from these 
> config files have the ADC functionality included:
> 
> https://github.com/machinekit/mksocfpga/tree/master/HW/hm2/config/DE0_Nano_SoC_Cramps

So in a nutshell (that I understand correctly):
I need to add this line to a DB25 configuration?
https://github.com/machinekit/mksocfpga/blob/master/HW/hm2/config/DE0_Nano_SoC_Cramps/PIN_3x24.vhd#L82

> The Adc functionality is only implemented in the new recently added DE0 / 
> DE10(commit pending) Nano SoC configs
> 
> https://github.com/the-snowwhite/mksocfpga/tree/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_FB_Cramps
> 
> https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE0_Nano_SoC_Cramps
> 
> For the CRAMPS board initially:
> 
> First exercise was to get the CRAMPS board added for the fpga socs and the 
> universal soc_adc drivers / soc_adc_temp usercomponent added to machinekit
> 
> I have posted a thread linking to a demo sd Image that will boot the DE10 
> with 1024x768 screen desktop
> And also boot the DE0_Nano_SoC in ssh -X konsole mode.
> 
> Generated via my updated soc_buildscripts @ github
> 
> The CRAMPS only version is an evolvement step towards Implementing a new 
> systemverilog based config structure I have been working on visible in my 
> mksocfpga3 repo, reduced to only include what is needed for utilizng all 
> functionality of the CRAMPS I/O board.
> 
> It may be simple to add the DB25.7I76_7I76_7I76_7I76.dtbo and needed cores as 
> an additional config to these 2 _CRAMPS quartus projects.
> 
> However I do not have a DB 25 adaptor or a mesa 7I76_7I76 available for 
> testing, therefore the CRAMPS version first :-)

Well, you do not have to have the adaptor. As long as the ADC can be tested on 
the ADC header that should be sufficient. All pins and stepgens will be made in 
HAL, so no need to see moving parts.

> 
> I you need the ADC functionality in the DB25_ quartus project you will have 
> to involve an VHDL expert to add the ADC hardware core into this VHDL only 
> quartus project, as I can only read/modify VHDL code not construct in this 
> language.
> 
> BTW aso hidden in the New CRAMPS HW configs is full gpio_0/1 mux 
> functionality, yet to be implemented in MK software:
> 
> https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/Common/gpio_adr_decoder_reg.sv#L26

Sorry, that’s out of my area of expertise :)

> 
> 
> On Wednesday, 30 August 2017 15:24:29 UTC+2, Bas de Bruijn wrote:
> 
> 
> On Monday, August 28, 2017 at 9:35:16 AM UTC+2, Bas de Bruijn wrote:
> 
> 
> On Sunday, August 27, 2017 at 4:15:59 PM UTC+2, Michael Brown wrote:
> The 2 (tested) commits are now online:
> 
> https://github.com/machinekit/mksocfpga/pull/87 
> 
> https://github.com/machinekit/machinekit/pull/1253 
> 
> 
> Sounds great Michael!
> I'll be updating my De0-nano board and I'll be trying out the ADC!
> Superb!
> 
> Bas
> 
> Michael B,
> Are there any additional requirements on using the ADC?
> I load an existing configuration, and try to see the ADC inputs change 
> (potmeter attached to pins)
> 
> machinekit@mksocfpga:~$ export DEBUG=5
> machinekit@mksocfpga:~$ halrun -I
> msgd:0 stopped
> rtapi:0 stopped
> halcmd: loadrt hostmot2
> :2: Realtime module 'hostmot2' loaded
> halcmd: newinst hm2_soc_ol hm2-socfpga0 -- 
> config="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo 
> num_stepgens=5 enable_adc=1" debug=1
> :3: Realtime module 'hm2_soc_ol' loaded
> halcmd: show funct
> Exported Functions:
>   Comp   Inst CodeAddr  Arg   FP   Users TypeName
> 66b6685725    NO   0 userdelinst
> 80 82 b559cecd  0003b588  NO   0 xthread 
> hm2_de0n.0.pet_watchdog
> 80 82 b5586005  0003b588  YES  0 xthread hm2_de0n.0.read
> 80 82 b5586191  0003b588  YES  0 xthread 
> hm2_de0n.0.read_gpio
> 80 82 b55860c5  0003b588  YES  0 xthread hm2_de0n.0.write
> 80 82 b55861c1  0003b588  YES  0 xthread 
> hm2_de0n.0.write_gpio
> 66b66855d5    NO   0 usernewinst
> 
> halcmd: newthread st 100 fp
> halcmd: addf hm2_de0n.0.read st
> :7: Function 'hm2_de0n.0.read' added to thread 'st', rmb=0 wmb=0
> halcmd: addf hm2_de0n.0.write st
> :8: Function 'hm2_de0n.0.write' added to thread 'st', rmb=0 wmb=0
> halcmd: addf hm2_de0n.0.pet_watchdog st
> :9: Function 'hm2_de0n.0.pet_watchdog' added to thread 'st', rmb=0 
> wmb=0
> halcmd: show pin hm2_de0n.0.nano_soc_adc.ch 
> 
> Component Pins:
>   Comp   Inst

Re: [Machinekit] Re: M-Code errors

2017-08-30 Thread Bas de Bruijn 


On 31 Aug 2017, at 07:07, Pranav Pandey  wrote:

>> Your g-code file works with the extruder as 'E' axis, and Machinekit uses 
>> the 'A' after the X, Y and Z axes.
>> Change your slicing printer settings so that Gcode flavor is "Mach3/LinuxCNC"
> 
> This worked. I successfully imported the g-code into Axis UI, but when I 
> start executing the file an error pops up on the bottom saying " Unknown m 
> code used: M190". I have read Machinekit supports this m code and it 
> instructs the system to wait till the bed temperature reaches the target 
> temperature.

Which configuration do you use? Please provide a link to the file in your own 
or the machinekit repo so we can see.

> 
> I have attached the error snapshot here. I have used this plugin for Cura: 
> https://github.com/machinekoder/uni-print-3d-cura
> 
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.
> 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Michael Brown 
Yes seems like we agree :-)

On Wednesday, 30 August 2017 15:06:07 UTC+2, Charles Steinkuehler wrote:
>
> Upon further reflection, the "mandatory" uio device name should be 
> optional and have a sensible default if it's not passed on the command 
> line.  The optional device tree overlay name should not (so the driver 
> doesn't do anything with loading/unloading device tree overlays if a 
> specific overlay name isn't passed in). 
>
> On 8/30/2017 7:57 AM, Charles Steinkuehler wrote: 
> > I think that's the right direction, but I'm not sure just removing the 
> > check for DTOV_STAT_APPLIED is safe in all instances.  I'd have to 
> > crawl through the hm2_soc code (not enough time right now), but from 
> > memory, I think it would be better to pass two strings to the code. 
> > One string (mandatory) would indicate the uio device name to use for 
> > mapping the memory region and interrupt.  The second (optional) string 
> > would indicate a device-tree file to attempt to load/unload. 
> > 
> > So without a device-tree overlay string, the driver will fail to load 
> > if it doesn't find the proper uio device.  When passed a device-tree 
> > overlay string, the driver should behave as it does now (attempt to 
> > load or unload/reload the overlay). 
> > 
> > How does that sound? 
> > 
> > On 8/30/2017 6:22 AM, Michael Brown wrote: 
> >> Personaly I think that this would be a more elegant solution, removing 
> the 
> >> requirement to Always load the device-tree-overlay at machinekit 
> launch: 
> >> 
> >> *the-snowwhite/machinekit@*bb33c62 
> >>  
> >> 
> >> 
> >> On Wednesday, 30 August 2017 09:31:35 UTC+2, Michael Brown wrote: 
> >>> 
> >>> OK nice 
> >>> There were some issues with the original image I have worked them out 
> and 
> >>> uploaded new tested images today. 
> >>> 
> >>> I found a different workaround which I have created an Issue on: 
> >>> https://github.com/machinekit/machinekit/issues/1261 
> >>> 
> >>> Maybe someone can figure out how to mod the hm2_soc_ol driver so the 
> >>> machinekit mesa soc can run without forcing the load of the dtbo.. ? 
> >>> 
> >>> I have commited my DE10_Nano quartus project here: 
> >>> https://github.com/machinekit/mksocfpga/pull/88 
> >>> 
> >>> Meanwhile: 
> >>> 
> >>> 
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
> >>> <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>
>  
>
> >>> 
> >>> How do I change the template so it only affects the 
> DE10_Nano_FB_Cramps 
> >>> dtbo ? 
> >>> 
> >>> 
> >>> 
> >>> On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote: 
>  
>  Nice!!! 
>  
>  To fix the hm2_soc_ol problem, just update the device tree file so it 
>  doesn't try to program the FPGA.  Replace (or comment) the 
>  "firmware-name" line: 
>  
>  
>  
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
>  <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>
>  
>
>  
>  ...with a tag indicating the FPGA is programmed already: 
>  
>    external-fpga-config = <1>; 
>  
>  This will keep the kernel from trying to (re)program the FPGA when 
> you 
>  load the overlay.  Everything else (address ranges, IRQ numbers, etc) 
>  should be OK and not need any changes. 
>  
>  On 8/29/2017 8:32 AM, Michael Brown wrote: 
> > DE10_Nano hdmi with 1024x768 works 
> > This image also boot directly on the DE0_Nano_SoC without 
> programming 
>  the 
> > fpga @boot (tested to work with mk) 
> > 
> > The hm2_soc_ol driver needs an update to be able to accept fpga 
>  configured 
> > from u-boot at boot. 
> > 
> > Install notes: 
> > 
>  
> https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
>  
> > 
> > :-) 
> > Michael 
> > 
> > On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
> >> 
> >> Michael Brown  has invited you to 
> *contribute 
> >> to* the following shared folder: 
> >> DE10-DE0-Nano 
> >> < 
>  
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>
>  
>
>  
> >> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
> >> framebuffer 
> >> This image also works with the Atlas (DE0-Nano-Soc) board(tested) 
> >> Open 
> >> < 
>  
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>
>  
>
>  
> >> Google Drive: Have all your files within r

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Michael Brown 
Under all circumstances the driver will fail and unload the hal is any of 
the signatures are missing or incorrect
and will sometimes cause a kernel panic, this would IMHO be better to use 
time on solving.

Testing for device-tree overlay loaded or not is redundant overkill IMHO.

Testing for uio driver(s)/ports and signature(s)  is a necessaty.


On Wednesday, 30 August 2017 14:57:50 UTC+2, Charles Steinkuehler wrote:
>
> I think that's the right direction, but I'm not sure just removing the 
> check for DTOV_STAT_APPLIED is safe in all instances.  I'd have to 
> crawl through the hm2_soc code (not enough time right now), but from 
> memory, I think it would be better to pass two strings to the code. 
> One string (mandatory) would indicate the uio device name to use for 
> mapping the memory region and interrupt.  The second (optional) string 
> would indicate a device-tree file to attempt to load/unload. 
>
> So without a device-tree overlay string, the driver will fail to load 
> if it doesn't find the proper uio device.  When passed a device-tree 
> overlay string, the driver should behave as it does now (attempt to 
> load or unload/reload the overlay). 
>
> How does that sound? 
>
> On 8/30/2017 6:22 AM, Michael Brown wrote: 
> > Personaly I think that this would be a more elegant solution, removing 
> the 
> > requirement to Always load the device-tree-overlay at machinekit launch: 
> > 
> > *the-snowwhite/machinekit@*bb33c62 
> >  
> > 
> > 
> > On Wednesday, 30 August 2017 09:31:35 UTC+2, Michael Brown wrote: 
> >> 
> >> OK nice 
> >> There were some issues with the original image I have worked them out 
> and 
> >> uploaded new tested images today. 
> >> 
> >> I found a different workaround which I have created an Issue on: 
> >> https://github.com/machinekit/machinekit/issues/1261 
> >> 
> >> Maybe someone can figure out how to mod the hm2_soc_ol driver so the 
> >> machinekit mesa soc can run without forcing the load of the dtbo.. ? 
> >> 
> >> I have commited my DE10_Nano quartus project here: 
> >> https://github.com/machinekit/mksocfpga/pull/88 
> >> 
> >> Meanwhile: 
> >> 
> >> 
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
> >> <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>
>  
>
> >> 
> >> How do I change the template so it only affects the DE10_Nano_FB_Cramps 
> >> dtbo ? 
> >> 
> >> 
> >> 
> >> On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote: 
> >>> 
> >>> Nice!!! 
> >>> 
> >>> To fix the hm2_soc_ol problem, just update the device tree file so it 
> >>> doesn't try to program the FPGA.  Replace (or comment) the 
> >>> "firmware-name" line: 
> >>> 
> >>> 
> >>> 
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
> >>> <
> https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmksocfpga%2Fblob%2Fmaster%2FSW%2FMK%2Fdts-overlays%2Ftemplate.dts%23L10&sa=D&sntz=1&usg=AFQjCNE4OX4cvh7893gll32zCKNaXx0y5w>
>  
>
> >>> 
> >>> ...with a tag indicating the FPGA is programmed already: 
> >>> 
> >>>   external-fpga-config = <1>; 
> >>> 
> >>> This will keep the kernel from trying to (re)program the FPGA when you 
> >>> load the overlay.  Everything else (address ranges, IRQ numbers, etc) 
> >>> should be OK and not need any changes. 
> >>> 
> >>> On 8/29/2017 8:32 AM, Michael Brown wrote: 
>  DE10_Nano hdmi with 1024x768 works 
>  This image also boot directly on the DE0_Nano_SoC without programming 
> >>> the 
>  fpga @boot (tested to work with mk) 
>  
>  The hm2_soc_ol driver needs an update to be able to accept fpga 
> >>> configured 
>  from u-boot at boot. 
>  
>  Install notes: 
>  
> >>> 
> https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
>  
>  
>  :-) 
>  Michael 
>  
>  On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
> > 
> > Michael Brown  has invited you to *contribute 
> > to* the following shared folder: 
> > DE10-DE0-Nano 
> > < 
> >>> 
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>
>  
>
> >>> 
> > [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
> > framebuffer 
> > This image also works with the Atlas (DE0-Nano-Soc) board(tested) 
> > Open 
> > < 
> >>> 
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>
>  
>
> >>> 
> > Google Drive: Have all your files within reach from any device. 
> > Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 
> >>> [image: 
> > Logo for Google Drive]  
> > 
>  
> >>> 
> >

Re: [Machinekit] Re: Reading current/torque from Mesa motion cards

2017-08-30 Thread Michael Brown 
Yes (ADC functionality is not added to the bitfiles from that Quartus 
project: 
 
https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE0_Nano_SoC_DB25)

Initially only the recent added 3 new .rbf bitfiles, generated from these 
config files have the ADC functionality included:

https://github.com/machinekit/mksocfpga/tree/master/HW/hm2/config/DE0_Nano_SoC_Cramps


The Adc functionality is only implemented in the new recently added DE0 / 
DE10(commit pending) Nano SoC configs

https://github.com/the-snowwhite/mksocfpga/tree/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_FB_Cramps

https://github.com/machinekit/mksocfpga/tree/master/HW/QuartusProjects/DE0_Nano_SoC_Cramps

For the CRAMPS board initially:

First exercise was to get the CRAMPS board added for the fpga socs and the 
universal soc_adc drivers / soc_adc_temp usercomponent added to machinekit

I have posted a thread linking to a demo sd Image that will boot the DE10 
with 1024x768 screen desktop
And also boot the DE0_Nano_SoC in ssh -X konsole mode.

Generated via my updated soc_buildscripts @ github

The CRAMPS only version is an evolvement step towards Implementing a new 
systemverilog based config structure I have been working on visible in my 
mksocfpga3 repo, reduced to only include what is needed for utilizng all 
functionality of the CRAMPS I/O board.

It may be simple to add the DB25.7I76_7I76_7I76_7I76.dtbo and needed cores 
as an additional config to these 2 _CRAMPS quartus projects.

However I do not have a DB 25 adaptor or a mesa 7I76_7I76 available for 
testing, therefore the CRAMPS version first :-)

I you need the ADC functionality in the DB25_ quartus project you will have 
to involve an VHDL expert to add the ADC hardware core into this VHDL only 
quartus project, as I can only read/modify VHDL code not construct in this 
language.

BTW aso hidden in the New CRAMPS HW configs is full gpio_0/1 mux 
functionality, yet to be implemented in MK software:

https://github.com/machinekit/mksocfpga/blob/master/HW/QuartusProjects/Common/gpio_adr_decoder_reg.sv#L26


On Wednesday, 30 August 2017 15:24:29 UTC+2, Bas de Bruijn wrote:
>
>
>
> On Monday, August 28, 2017 at 9:35:16 AM UTC+2, Bas de Bruijn wrote:
>>
>>
>>
>> On Sunday, August 27, 2017 at 4:15:59 PM UTC+2, Michael Brown wrote:
>>>
>>> The 2 (tested) commits are now online:
>>>
>>> https://github.com/machinekit/mksocfpga/pull/87
>>> https://github.com/machinekit/machinekit/pull/1253
>>>
>>
>> Sounds great Michael!
>> I'll be updating my De0-nano board and I'll be trying out the ADC!
>> Superb!
>>
>> Bas
>>
>
> Michael B,
> Are there any additional requirements on using the ADC?
> I load an existing configuration, and try to see the ADC inputs change 
> (potmeter attached to pins)
>
> machinekit@mksocfpga:~$ export DEBUG=5
> machinekit@mksocfpga:~$ halrun -I
> msgd:0 stopped
> rtapi:0 stopped
> halcmd: loadrt hostmot2
> :2: Realtime module 'hostmot2' loaded
> halcmd: newinst hm2_soc_ol hm2-socfpga0 -- 
> config="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo 
> num_stepgens=5 enable_adc=1" debug=1
> :3: Realtime module 'hm2_soc_ol' loaded
> halcmd: show funct
> Exported Functions:
>   Comp   Inst CodeAddr  Arg   FP   Users TypeName
> 66b6685725    NO   0 userdelinst
> 80 82 b559cecd  0003b588  NO   0 xthread 
> hm2_de0n.0.pet_watchdog
> 80 82 b5586005  0003b588  YES  0 xthread 
> hm2_de0n.0.read
> 80 82 b5586191  0003b588  YES  0 xthread 
> hm2_de0n.0.read_gpio
> 80 82 b55860c5  0003b588  YES  0 xthread 
> hm2_de0n.0.write
> 80 82 b55861c1  0003b588  YES  0 xthread 
> hm2_de0n.0.write_gpio
> 66b66855d5    NO   0 usernewinst
>
> halcmd: newthread st 100 fp
> halcmd: addf hm2_de0n.0.read st
> :7: Function 'hm2_de0n.0.read' added to thread 'st', rmb=0 wmb=0
> halcmd: addf hm2_de0n.0.write st
> :8: Function 'hm2_de0n.0.write' added to thread 'st', rmb=0 wmb=0
> halcmd: addf hm2_de0n.0.pet_watchdog st
> :9: Function 'hm2_de0n.0.pet_watchdog' added to thread 'st', rmb=0 
> wmb=0
> halcmd: show pin hm2_de0n.0.nano_soc_adc.ch
> Component Pins:
>   Comp   Inst Type  Dir Value  
> NameEpsilon Flags  linked to:
> 80 82 u32   OUT0x  
> hm2_de0n.0.nano_soc_adc.ch.0.out--l-
> 80 82 u32   OUT0x  
> hm2_de0n.0.nano_soc_adc.ch.1.out--l-
> 80 82 u32   OUT0x  
> hm2_de0n.0.nano_soc_adc.ch.2.out--l-
> 80 82 u32   OUT0x  
> hm2_de0n.0.nano_soc_adc.ch.3.out--l-
> 80 82 u32   OUT0x  
> hm2_de0n.0.nano_soc_adc.ch.4.out--l-
> 80 82 u32   OUT0x  
> hm2_de0n.0.nano_soc_adc.ch.5.out--l-
> 80 82 u32   OUT0x  
> hm2_de0n.0.nano_soc_adc.ch.6.out

[Machinekit] Re: M-Code errors

2017-08-30 Thread Daren Schwenke 
The Cura plugin also requires you to create a machine that uses it.  
It's also made for velocity extrusion, so you would need to use a config 
that also uses velocity extrusion.  It's one or the other.
Then you will be outputting ngc files instead of gcode, and E/A will 
disappear.  
E/A will be replaced by commands to 'start extruding' and 'stop extruding'. 
 How much to extrude will be dynamically calculated.

On Wednesday, August 30, 2017 at 10:24:20 AM UTC-4, Pranav Pandey wrote:
>
> If you want to simplify your life, and don't mind a remote interface, I 
>> would go a little different route.  
>> Axis still sucks on the BBB due to software rendering sucking up most of 
>> the CPU.  The solution to that is use a remote interface.  The one for 3D 
>> printing is 'Machineface'.
>> That and the trajectory planner doesn't work as well with > 3 axis.  The 
>> solution to that is 'velocity extrusion'.  There is no E then, so 3 axis 
>> will do it.
>>
>
> Thanks for this !
>  
>
>> Start here:
>> http://machinekoder.com/machinekit-and-cura/ for integrating cura.  It's 
>> a plugin to directly produce the ngc files from cura which velocity 
>> extrusion uses.  
>> The reason you are getting the errors is differences in what the slicers 
>> output compared to real gcode.  They break some rules from real gcode, and 
>> add some things.
>>
>
> I tried integrating Cura plugin but am still encountering M code errors. 
> :( 
>  
>
>> Here is a config made for Machineface and velocity extrusion.
>> https://github.com/machinekoder/Fabrikator-Mini-CRAMPS
>> This has been integrated into machinekit though, so you'll find it in 
>> configs, and it's built for CRAMPS too I believe.
>>
>
> The one integrated into machinekit is not working. The CRAMPS config is 
> fine but this one and few others are not working. A long list of error file 
> pops up.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: M-Code errors

2017-08-30 Thread Bas de Bruijn 


On Wednesday, August 30, 2017 at 5:19:58 PM UTC+2, Pranav Pandey wrote:
>
> We can't guess what these errors are. Have a read at this:
>> http://www.machinekit.io/docs/getting-help/
>>
>
> Thanks for this!
>  
>
>>
>> Then pastebin your errors and provide a link so we can see.
>>
>
> I am providing the details here:
>
> 1. I am using CRAMPS configuration on the Machinekit running on BBB.
>
> 2. On importing g-code [attached file] from Cura 2.7 into the Axis UI I am 
> getting various M-Code errors at different lines. Initially I received an 
> error on M420 Code [which is for some lights turn on]. I removed this 
> g-code from the file after which I encountered error for these codes. [G76, 
> M66, M67, M68 ] [Attached the Snapshot of the error]
>

Your g-code file works with the extruder as 'E' axis, and Machinekit uses 
the 'A' after the X, Y and Z axes.
Change your slicing printer settings so that Gcode flavor is 
"Mach3/LinuxCNC"


> What is the possible reason behind these?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: M-Code errors

2017-08-30 Thread Pranav Pandey 
Thanks for the reply Bas. I should have provided more details.

So I will try to list them here:

1. CRAMPS Configuration
2. Cura 2.1 Version
3. G-Code [Attached below]
4.


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Aug 30, 2017 at 8:04 PM, Bas de Bruijn  wrote:

>
>
> On 30 Aug 2017, at 16:24, Pranav Pandey  wrote:
>
> If you want to simplify your life, and don't mind a remote interface, I
>> would go a little different route.
>> Axis still sucks on the BBB due to software rendering sucking up most of
>> the CPU.  The solution to that is use a remote interface.  The one for 3D
>> printing is 'Machineface'.
>> That and the trajectory planner doesn't work as well with > 3 axis.  The
>> solution to that is 'velocity extrusion'.  There is no E then, so 3 axis
>> will do it.
>>
>
> Thanks for this !
>
>
>> Start here:
>> http://machinekoder.com/machinekit-and-cura/ for integrating cura.  It's
>> a plugin to directly produce the ngc files from cura which velocity
>> extrusion uses.
>> The reason you are getting the errors is differences in what the slicers
>> output compared to real gcode.  They break some rules from real gcode, and
>> add some things.
>>
>
> I tried integrating Cura plugin but am still encountering M code errors.
> :(
>
>
>> Here is a config made for Machineface and velocity extrusion.
>> https://github.com/machinekoder/Fabrikator-Mini-CRAMPS
>> This has been integrated into machinekit though, so you'll find it in
>> configs, and it's built for CRAMPS too I believe.
>>
>
> The one integrated into machinekit is not working. The CRAMPS config is
> fine but this one and few others are not working. A long list of error file
> pops up.
>
>
> Hi Pranev,
>
> We can't guess what these errors are. Have a read at this:
> http://www.machinekit.io/docs/getting-help/
>
> Then pastebin your errors and provide a link so we can see.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: M-Code errors

2017-08-30 Thread Bas de Bruijn 


On 30 Aug 2017, at 16:24, Pranav Pandey  wrote:

>> If you want to simplify your life, and don't mind a remote interface, I 
>> would go a little different route.  
>> Axis still sucks on the BBB due to software rendering sucking up most of the 
>> CPU.  The solution to that is use a remote interface.  The one for 3D 
>> printing is 'Machineface'.
>> That and the trajectory planner doesn't work as well with > 3 axis.  The 
>> solution to that is 'velocity extrusion'.  There is no E then, so 3 axis 
>> will do it.
> 
> Thanks for this !
>  
>> Start here:
>> http://machinekoder.com/machinekit-and-cura/ for integrating cura.  It's a 
>> plugin to directly produce the ngc files from cura which velocity extrusion 
>> uses.  
>> The reason you are getting the errors is differences in what the slicers 
>> output compared to real gcode.  They break some rules from real gcode, and 
>> add some things.
> 
> I tried integrating Cura plugin but am still encountering M code errors. :( 
>  
>> Here is a config made for Machineface and velocity extrusion.
>> https://github.com/machinekoder/Fabrikator-Mini-CRAMPS
>> This has been integrated into machinekit though, so you'll find it in 
>> configs, and it's built for CRAMPS too I believe.
> 
> The one integrated into machinekit is not working. The CRAMPS config is fine 
> but this one and few others are not working. A long list of error file pops 
> up.

Hi Pranev,

We can't guess what these errors are. Have a read at this:
http://www.machinekit.io/docs/getting-help/

Then pastebin your errors and provide a link so we can see.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: M-Code errors

2017-08-30 Thread Pranav Pandey 

>
> If you want to simplify your life, and don't mind a remote interface, I 
> would go a little different route.  
> Axis still sucks on the BBB due to software rendering sucking up most of 
> the CPU.  The solution to that is use a remote interface.  The one for 3D 
> printing is 'Machineface'.
> That and the trajectory planner doesn't work as well with > 3 axis.  The 
> solution to that is 'velocity extrusion'.  There is no E then, so 3 axis 
> will do it.
>

Thanks for this !
 

> Start here:
> http://machinekoder.com/machinekit-and-cura/ for integrating cura.  It's 
> a plugin to directly produce the ngc files from cura which velocity 
> extrusion uses.  
> The reason you are getting the errors is differences in what the slicers 
> output compared to real gcode.  They break some rules from real gcode, and 
> add some things.
>

I tried integrating Cura plugin but am still encountering M code errors. :( 
 

> Here is a config made for Machineface and velocity extrusion.
> https://github.com/machinekoder/Fabrikator-Mini-CRAMPS
> This has been integrated into machinekit though, so you'll find it in 
> configs, and it's built for CRAMPS too I believe.
>

The one integrated into machinekit is not working. The CRAMPS config is 
fine but this one and few others are not working. A long list of error file 
pops up.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Reading current/torque from Mesa motion cards

2017-08-30 Thread Bas de Bruijn 


On Monday, August 28, 2017 at 9:35:16 AM UTC+2, Bas de Bruijn wrote:
>
>
>
> On Sunday, August 27, 2017 at 4:15:59 PM UTC+2, Michael Brown wrote:
>>
>> The 2 (tested) commits are now online:
>>
>> https://github.com/machinekit/mksocfpga/pull/87
>> https://github.com/machinekit/machinekit/pull/1253
>>
>
> Sounds great Michael!
> I'll be updating my De0-nano board and I'll be trying out the ADC!
> Superb!
>
> Bas
>

Michael B,
Are there any additional requirements on using the ADC?
I load an existing configuration, and try to see the ADC inputs change 
(potmeter attached to pins)

machinekit@mksocfpga:~$ export DEBUG=5
machinekit@mksocfpga:~$ halrun -I
msgd:0 stopped
rtapi:0 stopped
halcmd: loadrt hostmot2
:2: Realtime module 'hostmot2' loaded
halcmd: newinst hm2_soc_ol hm2-socfpga0 -- 
config="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo 
num_stepgens=5 enable_adc=1" debug=1
:3: Realtime module 'hm2_soc_ol' loaded
halcmd: show funct
Exported Functions:
  Comp   Inst CodeAddr  Arg   FP   Users TypeName
66b6685725    NO   0 userdelinst
80 82 b559cecd  0003b588  NO   0 xthread 
hm2_de0n.0.pet_watchdog
80 82 b5586005  0003b588  YES  0 xthread hm2_de0n.0.read
80 82 b5586191  0003b588  YES  0 xthread 
hm2_de0n.0.read_gpio
80 82 b55860c5  0003b588  YES  0 xthread 
hm2_de0n.0.write
80 82 b55861c1  0003b588  YES  0 xthread 
hm2_de0n.0.write_gpio
66b66855d5    NO   0 usernewinst

halcmd: newthread st 100 fp
halcmd: addf hm2_de0n.0.read st
:7: Function 'hm2_de0n.0.read' added to thread 'st', rmb=0 wmb=0
halcmd: addf hm2_de0n.0.write st
:8: Function 'hm2_de0n.0.write' added to thread 'st', rmb=0 wmb=0
halcmd: addf hm2_de0n.0.pet_watchdog st
:9: Function 'hm2_de0n.0.pet_watchdog' added to thread 'st', rmb=0 
wmb=0
halcmd: show pin hm2_de0n.0.nano_soc_adc.ch
Component Pins:
  Comp   Inst Type  Dir Value  
NameEpsilon Flags  linked to:
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.0.out--l-
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.1.out--l-
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.2.out--l-
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.3.out--l-
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.4.out--l-
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.5.out--l-
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.6.out--l-
80 82 u32   OUT0x  
hm2_de0n.0.nano_soc_adc.ch.7.out--l-

halcmd: start
:11: Realtime threads started
halcmd: show pin hm2_de0n.0.nano_soc_adc.ch
Component Pins:
  Comp   Inst Type  Dir Value  
NameEpsilon Flags  linked to:
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.0.out--l-
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.1.out--l-
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.2.out--l-
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.3.out--l-
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.4.out--l-
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.5.out--l-
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.6.out--l-
80 82 u32   OUT0x0001  
hm2_de0n.0.nano_soc_adc.ch.7.out--l-

On Tuesday, 15 August 2017 23:31:56 UTC+2, Michael Brown wrote:
>
> Thanks a lot that pushed me in the right direction.
>
> I now have my 2 python based Machineface configs fully up and running with 
> your cramps interface, temperature tmc2130 (spi mode) steppers, pwm etc all 
> fully functional.
>
> Schematics for cramps and pcb layouts for the new capasitive probe sensor 
> addition(KiCad), py-spi-dev and other related files 
> are now on github and I expect to have the (once again rebased)commits for 
> mksocfpga and machinekit ready to launch in beginning of next week when I 
> return to my workstation.
>
>
>
> On Monday, 17 July 2017 18:23:39 UTC+2, Charles Steinkuehler wrote:
>>
>> On 7/16/2017 3:09 PM, Michael Brown wrote: 
>> > Next I tried out with the image you pointed to only linking to these 
>> > instructions: docker pull cdsteinkuehler/jessie-quartus-15.1.2 this 
>> > gives me an image I then can start with: docker run -it 
>> > cdsteinkuehler/jessie-quartus-15.1.2 And then what ? 
>>
>> Follow the instructions here: 
>>
>>
>> https://github.com/cdsteinkuehler/mksocfpga/blob/master/README.MD#launch-a-docker-build-machine-with-the-latest-mksocfpga-source-code
>>  
>>
>> Basically, the steps are: 
>>
>> * Clone the mksocfpga repo 
>> * Launch docker with the repo moun

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Charles Steinkuehler 
Upon further reflection, the "mandatory" uio device name should be
optional and have a sensible default if it's not passed on the command
line.  The optional device tree overlay name should not (so the driver
doesn't do anything with loading/unloading device tree overlays if a
specific overlay name isn't passed in).

On 8/30/2017 7:57 AM, Charles Steinkuehler wrote:
> I think that's the right direction, but I'm not sure just removing the
> check for DTOV_STAT_APPLIED is safe in all instances.  I'd have to
> crawl through the hm2_soc code (not enough time right now), but from
> memory, I think it would be better to pass two strings to the code.
> One string (mandatory) would indicate the uio device name to use for
> mapping the memory region and interrupt.  The second (optional) string
> would indicate a device-tree file to attempt to load/unload.
> 
> So without a device-tree overlay string, the driver will fail to load
> if it doesn't find the proper uio device.  When passed a device-tree
> overlay string, the driver should behave as it does now (attempt to
> load or unload/reload the overlay).
> 
> How does that sound?
> 
> On 8/30/2017 6:22 AM, Michael Brown wrote:
>> Personaly I think that this would be a more elegant solution, removing the 
>> requirement to Always load the device-tree-overlay at machinekit launch:
>>
>> *the-snowwhite/machinekit@*bb33c62 
>> 
>>
>>
>> On Wednesday, 30 August 2017 09:31:35 UTC+2, Michael Brown wrote:
>>>
>>> OK nice
>>> There were some issues with the original image I have worked them out and 
>>> uploaded new tested images today.
>>>
>>> I found a different workaround which I have created an Issue on:
>>> https://github.com/machinekit/machinekit/issues/1261
>>>
>>> Maybe someone can figure out how to mod the hm2_soc_ol driver so the 
>>> machinekit mesa soc can run without forcing the load of the dtbo.. ?
>>>
>>> I have commited my DE10_Nano quartus project here:
>>> https://github.com/machinekit/mksocfpga/pull/88
>>>
>>> Meanwhile:
>>>
>>> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>>>  
>>> 
>>>
>>> How do I change the template so it only affects the DE10_Nano_FB_Cramps 
>>> dtbo ?
>>>
>>>
>>>
>>> On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote:

 Nice!!! 

 To fix the hm2_soc_ol problem, just update the device tree file so it 
 doesn't try to program the FPGA.  Replace (or comment) the 
 "firmware-name" line: 


 https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
  
 
  

 ...with a tag indicating the FPGA is programmed already: 

   external-fpga-config = <1>; 

 This will keep the kernel from trying to (re)program the FPGA when you 
 load the overlay.  Everything else (address ranges, IRQ numbers, etc) 
 should be OK and not need any changes. 

 On 8/29/2017 8:32 AM, Michael Brown wrote: 
> DE10_Nano hdmi with 1024x768 works 
> This image also boot directly on the DE0_Nano_SoC without programming 
 the 
> fpga @boot (tested to work with mk) 
>
> The hm2_soc_ol driver needs an update to be able to accept fpga 
 configured 
> from u-boot at boot. 
>
> Install notes: 
>
 https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
  
>
> :-) 
> Michael 
>
> On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
>>
>> Michael Brown  has invited you to *contribute 
>> to* the following shared folder: 
>> DE10-DE0-Nano 
>> <
 https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>
  

>> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
>> framebuffer 
>> This image also works with the Atlas (DE0-Nano-Soc) board(tested) 
>> Open 
>> <
 https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>
  

>> Google Drive: Have all your files within reach from any device. 
>> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 
 [image: 
>> Logo for Google Drive]  
>>
>


 -- 
 Charles Steinkuehler 
 cha...@steinkuehler.net 

>>>
>>
> 
> 


-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://g

Re: [Machinekit] world mode in machienkit

2017-08-30 Thread Charles Steinkuehler 
Check your CPU load and the time spent in each HAL module (it shows up
as a HAL signal).  I'm not sure the BBB has enough FPU performance to
handle some of the non-trivial kinematics setups.  You may need to
craft a higher performance solution based on your specific machine or
migrate to a more powerful platform (X15 or maybe an x86).

All the work I've done with "serious" non-trivial kinematics (ie:
genserkins vs. something like a delta-arm 3D printer) has been on an
x86, which has *LOTS* more CPU power than a BBB.

On 8/28/2017 9:15 PM, thangle wrote:
> i just have one more question, why everytime i change to world mode in 
> puma560 sim to jog or use MDI, the BBB become very lag and freeze.
> 
> Vào 18:25:48 UTC+7 Thứ Bảy, ngày 26 tháng 8 năm 2017, Charles Steinkuehler 
> đã viết:
>>
>> On 8/26/2017 12:20 AM, thangle wrote: 
>>> thank for answers, they are really helpful 
>>>
>>> Vào 03:20:16 UTC+7 Thứ Bảy, ngày 26 tháng 8 năm 2017, Charles 
>> Steinkuehler 
>>> đã viết: 

 On 8/24/2017 9:28 PM, thangle wrote: 
> I have some problems when i try configuring custom arm robot 6DOF. 
>> hope 
> someone can help me resolve these. 
>
> 1st. i run PUMA560 sim but i cant open "world mode" from AXIS GUI. 
> everytime i turn it on by "Alt+M" it return joint mode. if anyway to 
>> use 
> "world mode" in manual control 


>>> what should i do after home all joints, do i need to change somethings 
>> in 
>>> .hal file? I dont have a real machine yet, just beaglebone black but i 
>> want 
>>> to simulator them first 
>>
>> IIRC, after executing "home all", the Axis GUI will switch to world 
>> mode automatically.  If it doesn't, there is a  menu item to toggle 
>> between joint and world mode. 
>>
>> -- 
>> Charles Steinkuehler 
>> cha...@steinkuehler.net  
>>
> 


-- 
Charles Steinkuehler
char...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Charles Steinkuehler 
I think that's the right direction, but I'm not sure just removing the
check for DTOV_STAT_APPLIED is safe in all instances.  I'd have to
crawl through the hm2_soc code (not enough time right now), but from
memory, I think it would be better to pass two strings to the code.
One string (mandatory) would indicate the uio device name to use for
mapping the memory region and interrupt.  The second (optional) string
would indicate a device-tree file to attempt to load/unload.

So without a device-tree overlay string, the driver will fail to load
if it doesn't find the proper uio device.  When passed a device-tree
overlay string, the driver should behave as it does now (attempt to
load or unload/reload the overlay).

How does that sound?

On 8/30/2017 6:22 AM, Michael Brown wrote:
> Personaly I think that this would be a more elegant solution, removing the 
> requirement to Always load the device-tree-overlay at machinekit launch:
> 
> *the-snowwhite/machinekit@*bb33c62 
> 
> 
> 
> On Wednesday, 30 August 2017 09:31:35 UTC+2, Michael Brown wrote:
>>
>> OK nice
>> There were some issues with the original image I have worked them out and 
>> uploaded new tested images today.
>>
>> I found a different workaround which I have created an Issue on:
>> https://github.com/machinekit/machinekit/issues/1261
>>
>> Maybe someone can figure out how to mod the hm2_soc_ol driver so the 
>> machinekit mesa soc can run without forcing the load of the dtbo.. ?
>>
>> I have commited my DE10_Nano quartus project here:
>> https://github.com/machinekit/mksocfpga/pull/88
>>
>> Meanwhile:
>>
>> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>>  
>> 
>>
>> How do I change the template so it only affects the DE10_Nano_FB_Cramps 
>> dtbo ?
>>
>>
>>
>> On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote:
>>>
>>> Nice!!! 
>>>
>>> To fix the hm2_soc_ol problem, just update the device tree file so it 
>>> doesn't try to program the FPGA.  Replace (or comment) the 
>>> "firmware-name" line: 
>>>
>>>
>>> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>>>  
>>> 
>>>  
>>>
>>> ...with a tag indicating the FPGA is programmed already: 
>>>
>>>   external-fpga-config = <1>; 
>>>
>>> This will keep the kernel from trying to (re)program the FPGA when you 
>>> load the overlay.  Everything else (address ranges, IRQ numbers, etc) 
>>> should be OK and not need any changes. 
>>>
>>> On 8/29/2017 8:32 AM, Michael Brown wrote: 
 DE10_Nano hdmi with 1024x768 works 
 This image also boot directly on the DE0_Nano_SoC without programming 
>>> the 
 fpga @boot (tested to work with mk) 

 The hm2_soc_ol driver needs an update to be able to accept fpga 
>>> configured 
 from u-boot at boot. 

 Install notes: 

>>> https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
>>>  

 :-) 
 Michael 

 On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
>
> Michael Brown  has invited you to *contribute 
> to* the following shared folder: 
> DE10-DE0-Nano 
> <
>>> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>
>>>  
>>>
> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
> framebuffer 
> This image also works with the Atlas (DE0-Nano-Soc) board(tested) 
> Open 
> <
>>> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>
>>>  
>>>
> Google Drive: Have all your files within reach from any device. 
> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 
>>> [image: 
> Logo for Google Drive]  
>

>>>
>>>
>>> -- 
>>> Charles Steinkuehler 
>>> cha...@steinkuehler.net 
>>>
>>
> 


-- 
Charles Steinkuehler
char...@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.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Michael Brown 
I setup a pull request on the remove dt-overlay on Machinekit launch 
requirement, issue as I may be away for some days.

https://github.com/machinekit/machinekit/pull/1263


On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote:
>
> Michael Brown  has invited you to *contribute 
> to* the following shared folder:
> DE10-DE0-Nano 
> 
> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
> framebuffer
> This image also works with the Atlas (DE0-Nano-Soc) board(tested)
> Open 
> 
> Google Drive: Have all your files within reach from any device. 
> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA [image: 
> Logo for Google Drive] 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Michael Brown 
Personaly I think that this would be a more elegant solution, removing the 
requirement to Always load the device-tree-overlay at machinekit launch:

*the-snowwhite/machinekit@*bb33c62 



On Wednesday, 30 August 2017 09:31:35 UTC+2, Michael Brown wrote:
>
> OK nice
> There were some issues with the original image I have worked them out and 
> uploaded new tested images today.
>
> I found a different workaround which I have created an Issue on:
> https://github.com/machinekit/machinekit/issues/1261
>
> Maybe someone can figure out how to mod the hm2_soc_ol driver so the 
> machinekit mesa soc can run without forcing the load of the dtbo.. ?
>
> I have commited my DE10_Nano quartus project here:
> https://github.com/machinekit/mksocfpga/pull/88
>
> Meanwhile:
>
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
> 
>
> How do I change the template so it only affects the DE10_Nano_FB_Cramps 
> dtbo ?
>
>
>
> On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote:
>>
>> Nice!!! 
>>
>> To fix the hm2_soc_ol problem, just update the device tree file so it 
>> doesn't try to program the FPGA.  Replace (or comment) the 
>> "firmware-name" line: 
>>
>>
>> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>>  
>> 
>>  
>>
>> ...with a tag indicating the FPGA is programmed already: 
>>
>>   external-fpga-config = <1>; 
>>
>> This will keep the kernel from trying to (re)program the FPGA when you 
>> load the overlay.  Everything else (address ranges, IRQ numbers, etc) 
>> should be OK and not need any changes. 
>>
>> On 8/29/2017 8:32 AM, Michael Brown wrote: 
>> > DE10_Nano hdmi with 1024x768 works 
>> > This image also boot directly on the DE0_Nano_SoC without programming 
>> the 
>> > fpga @boot (tested to work with mk) 
>> > 
>> > The hm2_soc_ol driver needs an update to be able to accept fpga 
>> configured 
>> > from u-boot at boot. 
>> > 
>> > Install notes: 
>> > 
>> https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
>>  
>> > 
>> > :-) 
>> > Michael 
>> > 
>> > On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
>> >> 
>> >> Michael Brown  has invited you to *contribute 
>> >> to* the following shared folder: 
>> >> DE10-DE0-Nano 
>> >> <
>> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>
>>  
>>
>> >> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
>> >> framebuffer 
>> >> This image also works with the Atlas (DE0-Nano-Soc) board(tested) 
>> >> Open 
>> >> <
>> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>
>>  
>>
>> >> Google Drive: Have all your files within reach from any device. 
>> >> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 
>> [image: 
>> >> Logo for Google Drive]  
>> >> 
>> > 
>>
>>
>> -- 
>> 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.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Michael Brown 
Well my Image is actually a 2 part Image with an added swap partition as 
partition2.
the ext4 rootfs partition was the moved to the last partition (3) so that 
is easily can be expanded by just resizing the last partition... :-) 

A2 (for u-boot-with-spl.sfp), swap and ext4 (for rootfs)

On Tuesday, 29 August 2017 19:01:01 UTC+2, mugginsac wrote:
>
> Michael,
> Actually I have a couple questions for you.
> First, is your image still using three partitions A2, Fat, and ext4?
> Second, I cant find the source file "include/config_cmd_all.h". Is it part 
> of u-boot??
>
> Yes:
file:///home/mib/Development/MK-Image-gen/uboot/include/config_cmd_all.h

 

> I am trying to cut down to just two partitions. Initially A2 (for 
> u-boot-with-spl.sfp) and ext4 (for rootfs). 
> I have had it boot but not consistently.
>
> Thanks,
> Alan
> On Tuesday, August 29, 2017 at 6:05:32 AM UTC-7, Michael Brown wrote:
>>
>> Michael Brown has invited you to *contribute to* the following shared 
>> folder:
>> DE10-DE0-Nano 
>> 
>> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
>> framebuffer
>> This image also works with the Atlas (DE0-Nano-Soc) board(tested)
>> Open 
>> 
>> Google Drive: Have all your files within reach from any device. 
>> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA [image: 
>> Logo for Google Drive] 
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: DE10-DE0-Nano - Invitation to collaborate

2017-08-30 Thread Michael Brown 
OK nice
There were some issues with the original image I have worked them out and 
uploaded new tested images today.

I found a different workaround which I have created an Issue on:
https://github.com/machinekit/machinekit/issues/1261

Maybe someone can figure out how to mod the hm2_soc_ol driver so the 
machinekit mesa soc can run without forcing the load of the dtbo.. ?

I have commited my DE10_Nano quartus project here:
https://github.com/machinekit/mksocfpga/pull/88

Meanwhile:
https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
 


How do I change the template so it only affects the DE10_Nano_FB_Cramps 
dtbo ?



On Tuesday, 29 August 2017 16:10:01 UTC+2, Charles Steinkuehler wrote:
>
> Nice!!! 
>
> To fix the hm2_soc_ol problem, just update the device tree file so it 
> doesn't try to program the FPGA.  Replace (or comment) the 
> "firmware-name" line: 
>
>
> https://github.com/machinekit/mksocfpga/blob/master/SW/MK/dts-overlays/template.dts#L10
>  
> 
>  
>
> ...with a tag indicating the FPGA is programmed already: 
>
>   external-fpga-config = <1>; 
>
> This will keep the kernel from trying to (re)program the FPGA when you 
> load the overlay.  Everything else (address ranges, IRQ numbers, etc) 
> should be OK and not need any changes. 
>
> On 8/29/2017 8:32 AM, Michael Brown wrote: 
> > DE10_Nano hdmi with 1024x768 works 
> > This image also boot directly on the DE0_Nano_SoC without programming 
> the 
> > fpga @boot (tested to work with mk) 
> > 
> > The hm2_soc_ol driver needs an update to be able to accept fpga 
> configured 
> > from u-boot at boot. 
> > 
> > Install notes: 
> > 
> https://github.com/the-snowwhite/mksocfpga/blob/DE10_Nano_FB_Cramps/HW/QuartusProjects/DE10_Nano_Commands.md
>  
> > 
> > :-) 
> > Michael 
> > 
> > On Tuesday, 29 August 2017 15:05:32 UTC+2, Michael Brown wrote: 
> >> 
> >> Michael Brown > has invited you to 
> *contribute 
> >> to* the following shared folder: 
> >> DE10-DE0-Nano 
> >> <
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eil&ts=59a5669b>
>  
>
> >> [image: Sender's profile photo]DE10-SoC Machinekit demo image with 
> >> framebuffer 
> >> This image also works with the Atlas (DE0-Nano-Soc) board(tested) 
> >> Open 
> >> <
> https://drive.google.com/drive/folders/0BwyLvgyVIdi8ZG1vYTFzc01EOXc?usp=sharing_eip&ts=59a5669b>
>  
>
> >> Google Drive: Have all your files within reach from any device. 
> >> Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA 
> [image: 
> >> Logo for Google Drive]  
> >> 
> > 
>
>
> -- 
> 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.
For more options, visit https://groups.google.com/d/optout.