Re: [Machinekit] Steprate Question

[Sag ich Dir nich]

Well i want to stay small so i have to look what speed in mm/min i will get 
out of it maximum

anyways thanks for the explanation

Am Montag, 12. Juni 2017 17:44:02 UTC+2 schrieb Chris Albertson:
>
> This sounds like a job for an FPGA.  1MHz loops are hard to do in 
> software.Even with custom PRU code, if it worked yours have job for 
> life maintaining it as new versions of the CNC software, OS and toolchain 
> come out over the coming years and decades.   
>
> Mesa cards are not that expensive and other FPGA cards can be 1/2 their 
> price.   So, just move the 1MHz loop into hardware.
>
> One problem with software is that when you look at  results at the 
> sub-microsecond level differences is the dynamic code path lengths matter. 
>   For example does it ALWAYS requires 15 clock cycles to turn on a bit?  
> No, likely there is an "if" statement some place where one branch is 
> longer.At low speeds this is a 0.01% effect at higher speeds this might 
> be a 10% effect.   You don't know the magnitude of the problem until after 
> you write the code and see if you were able to make every execution path 
> the same length.   Likely not so you have jitter at the XX% level.  
>
> This is where FPGAs work best because you can clock the output pluses 
> relative to a divided down crystal oscillator 
>
> On Mon, Jun 12, 2017 at 7:03 AM, Charles Steinkuehler <
> cha...@steinkuehler.net > wrote:
>
>> On 6/10/2017 1:06 PM, Sag ich Dir nich wrote:
>> > Hello,
>> >
>> > if i want to drive 5 axis with each 1 MHZ steprate, do i need to reach 
>> 5 MHZ
>> > Stepgen or 1 MHZ?
>>
>> You need to a 2 MHz base thread (or 500 nS PRU period) which will give
>> you a 1 MHz maximum step rate (1 thread period high, one thread period
>> low).
>>
>> This is very easy to do if you're using hardware, but not so easy in
>> software.  I doubt an x86 can run interrupts anywhere close to that
>> fast, and an ARM certainly can't.
>>
>> The PRU on a BBB can probably be coerced into running this fast, but
>> you'll need to optimize the code.  The existing hal_pru_generic was
>> written for flexibility more than absolute speed, and probably won't
>> go faster than several hundred KHz step rates with 5 stepgens.  To get
>> into MHz step rates, you'll probably need to hard-code the PRU logic
>> (instead of building a chain of "tasklets" as is done now) and keep
>> all of the state information in registers.  It should be fairly simple
>> to do, but you still might not quite make it to a 1 MHz step rate (the
>> 500 uS task period only gives you 100 instructions to do step/dir
>> generation for 5 channels, or 20 instructions per channel.  The
>> step/dir code isn't super complex, but is more than 20 instructions
>> through the worst-case path, and some of the instructions take more
>> than 1 clock (5 nS).  Getting rid of the memory accesses (required for
>> the current "tasklet" structure) and putting everything in registers
>> ought to get you close to the required speed.
>>
>> --
>> 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+...@googlegroups.com .
>> Visit this group at https://groups.google.com/group/machinekit.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Chris Albertson
> Redondo Beach, California
>

-- 
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] How to Calibrate the Machine to a Datum Tool and relatively measure other tools?

[Sag ich Dir nich]

okay thanks, ill have a look

Am Sonntag, 11. Juni 2017 08:21:31 UTC+2 schrieb Schooner:
>
>
>
> On 10/06/2017 12:02, Sag ich Dir nich wrote:
>
> Hello,  
>
> is it possible to use a datum Tool (known accurate length) to Calibrate 
> the machine to (if it hits a switch, back up then slowly hit it again and 
> then automatically enter the known length of the tool) and then measure 
> other tools relatively to the datum tool? Both should have their own Macro 
> -Button (so i can press "calibrate" once in the morning and then load a 
> unknown tool to measure its length afterwards)
>
>
> Yes
>
> This has been covered so many times on the Linuxcnc forum, you would be 
> best searching
> 'linuxcnc: tool length probe'. and working from there.
>
> Various solutions tend to use the probing routines to a known height 
> switch, but there are remapping solutions for manual toolchange with tool 
> length probe and all sorts out there.
>
>
> Thanks for any help
> -- 
> 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+...@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] Converting binary to number

[Bas de Bruijn]

> On 12 Jun 2017, at 17:33, Charles Steinkuehler  
> wrote:
> 
>> On 6/12/2017 10:22 AM, Bas de Bruijn wrote:
>> I've been looking thru the HAL components and I might have missed it. Before 
>> I write one, is there a component to convert binary inputs to a number?
>> 
>> Use case: super simple machine to machine communication by I/O. I read 2 
>> inputs and need to convert that to a number 0-3.
> 
> You can do that with mux4.  It has two bit inputs used to select one
> of four fp numbers.  Just set the inputs to be the appropriate constants.

Thanks! I knew I wasn't the first one to need this :)

> 
> -- 
> 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.

-- 
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] Steprate Question

[Chris Albertson]

This sounds like a job for an FPGA.  1MHz loops are hard to do in software.
   Even with custom PRU code, if it worked yours have job for life
maintaining it as new versions of the CNC software, OS and toolchain come
out over the coming years and decades.

Mesa cards are not that expensive and other FPGA cards can be 1/2 their
price.   So, just move the 1MHz loop into hardware.

One problem with software is that when you look at  results at the
sub-microsecond level differences is the dynamic code path lengths matter.
  For example does it ALWAYS requires 15 clock cycles to turn on a bit?
No, likely there is an "if" statement some place where one branch is
longer.At low speeds this is a 0.01% effect at higher speeds this might
be a 10% effect.   You don't know the magnitude of the problem until after
you write the code and see if you were able to make every execution path
the same length.   Likely not so you have jitter at the XX% level.

This is where FPGAs work best because you can clock the output pluses
relative to a divided down crystal oscillator

On Mon, Jun 12, 2017 at 7:03 AM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 6/10/2017 1:06 PM, Sag ich Dir nich wrote:
> > Hello,
> >
> > if i want to drive 5 axis with each 1 MHZ steprate, do i need to reach 5
> MHZ
> > Stepgen or 1 MHZ?
>
> You need to a 2 MHz base thread (or 500 nS PRU period) which will give
> you a 1 MHz maximum step rate (1 thread period high, one thread period
> low).
>
> This is very easy to do if you're using hardware, but not so easy in
> software.  I doubt an x86 can run interrupts anywhere close to that
> fast, and an ARM certainly can't.
>
> The PRU on a BBB can probably be coerced into running this fast, but
> you'll need to optimize the code.  The existing hal_pru_generic was
> written for flexibility more than absolute speed, and probably won't
> go faster than several hundred KHz step rates with 5 stepgens.  To get
> into MHz step rates, you'll probably need to hard-code the PRU logic
> (instead of building a chain of "tasklets" as is done now) and keep
> all of the state information in registers.  It should be fairly simple
> to do, but you still might not quite make it to a 1 MHz step rate (the
> 500 uS task period only gives you 100 instructions to do step/dir
> generation for 5 channels, or 20 instructions per channel.  The
> step/dir code isn't super complex, but is more than 20 instructions
> through the worst-case path, and some of the instructions take more
> than 1 clock (5 nS).  Getting rid of the memory accesses (required for
> the current "tasklet" structure) and putting everything in registers
> ought to get you close to the required speed.
>
> --
> 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.
>



-- 

Chris Albertson
Redondo Beach, California

-- 
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] Converting binary to number

[Charles Steinkuehler]

On 6/12/2017 10:22 AM, Bas de Bruijn wrote:
> I've been looking thru the HAL components and I might have missed it. Before 
> I write one, is there a component to convert binary inputs to a number?
> 
> Use case: super simple machine to machine communication by I/O. I read 2 
> inputs and need to convert that to a number 0-3.

You can do that with mux4.  It has two bit inputs used to select one
of four fp numbers.  Just set the inputs to be the appropriate constants.

-- 
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] DE0 Demonstration Projekt on Machinekit

[Charles Steinkuehler]

On 6/12/2017 1:04 AM, Basti wrote:
> 
> 
> On the board is the Quartus-Project DE0_NANO_SOC_GHRD from the-snowwhite. The 
> header file hps0.h have I generate form this projekt. But every time I make 
> it 
> run I get this error.
> 
> 
> I use gdb to debug:
> 
> 
> Program received signal SIGBUS, Bus error.
> 
> 0x8548 in main () at main.c:51
> 
> 51 *(uint32_t *)h2p_lw_led_addr = ~led_mask;

The FPGA based LED registers used in the example code are not present
in the precompiled hm2 based FPGA bit-files.  You will need to use an
FPGA design that has these GPIO registers in the FPGA fabric and make
sure the FPGA is programmed with that bit file.  The easiest way to do
this is probably to compile the FPGA design that should be part of the
same GHRD demo where you obtained the C code.

Once you have a bitfile, the FPGA can be programmed via u-boot, a
device-tree overlay file, or a JTAG download cable.  The Machinekit
image typically uses a device tree overlay, so if you're not manually
programming the FPGA it's probably not programmed.

If the FPGA is not programmed, or does not respond to the address
assigned to the LED registers, you will get a bus error.

-- 
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] Steprate Question

[Charles Steinkuehler]

On 6/10/2017 1:06 PM, Sag ich Dir nich wrote:
> Hello,
> 
> if i want to drive 5 axis with each 1 MHZ steprate, do i need to reach 5 MHZ 
> Stepgen or 1 MHZ?

You need to a 2 MHz base thread (or 500 nS PRU period) which will give
you a 1 MHz maximum step rate (1 thread period high, one thread period
low).

This is very easy to do if you're using hardware, but not so easy in
software.  I doubt an x86 can run interrupts anywhere close to that
fast, and an ARM certainly can't.

The PRU on a BBB can probably be coerced into running this fast, but
you'll need to optimize the code.  The existing hal_pru_generic was
written for flexibility more than absolute speed, and probably won't
go faster than several hundred KHz step rates with 5 stepgens.  To get
into MHz step rates, you'll probably need to hard-code the PRU logic
(instead of building a chain of "tasklets" as is done now) and keep
all of the state information in registers.  It should be fairly simple
to do, but you still might not quite make it to a 1 MHz step rate (the
500 uS task period only gives you 100 instructions to do step/dir
generation for 5 channels, or 20 instructions per channel.  The
step/dir code isn't super complex, but is more than 20 instructions
through the worst-case path, and some of the instructions take more
than 1 clock (5 nS).  Getting rid of the memory accesses (required for
the current "tasklet" structure) and putting everything in registers
ought to get you close to the required speed.

-- 
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.