Charles, Thanks for the detailed response. We have out cnc night tonight and given us much to look at.
I wouldn't mind giving it go developing it a go coming up with a configuration tool/GUI for the BBB. (Best way to learn about this stuff) I took a quick look at the source for stepconf and it appears to be glade/Python. I was debating if I should copy the code and just refactor it to handle a BBB or start from scratch with QT Python c/c++. Any thoughts? On Oct 11, 2016 10:48 AM, "Charles Steinkuehler" <[email protected]> wrote: > On 10/9/2016 4:34 PM, Tom M wrote: > > > > hpg: stepgen.01.maxvel is too big for current step timings & > position-scale, > > clipping to max possible > > > > joint 1 following error > > emc/task/taskintf.cc 617: Error on axis 1, command number 358 > > > > The clipping message is occurring when I toggle machine power. I'm > still able > > to run the demo gcode and I hit the joint follower when I'm finishing > the T in > > machine kit. > > The minimum stepper pulse times are one PRU task-cycle-time high and > one task-cycle-time low. So the maximum pulse frequency depends on > the requested step timings and the PRU task-period. Usually, the step > timings are in the range of a few hundred nS, and the PRU period is > thousands of nS, so usually the maximum step frequency is half the > task-period. > > You get the following error at the end because the machine is trying > to do a rapid move (maximum velocity) instead of a controlled velocity > cut. The motion planner is setup with a maximum velocity for an axis > that requires a step rate that the PRU code cannot generate given the > pru task-period, and the step timings. Very soon as the motion > planner commands this unattainable velocity, you will get a following > error as the PRU stepgen cannot keep up with the commanded position. > > > (at this point, I"m not connected to machine(it's in another state)). > I'm > > trying to understand the clipping to max possible message > > I had this issues working on my MPCNC project and Charles said. > > > > "This means the PRU cannot meet your requested maximum velocity (or > > step pulse frequency) given the PRU period and various other > > parameters (step pulse high/low time). You need to either lower the > > maximum velocity in your INI file or reduce the PRU period" > > > > How much can I/ should I reduce the PRU period... Going down to 5000 is > too > > much is it seems to break something else. > > I typically run with a PRU period of 3000 to 5000 nS without issue, > but it depends on how many PRU tasks (stepgen/pwmgen) you are trying > to run. If you have access to a direct PRU output pin, you can set it > up to be a PRU busy indicator and monitor the PRU loading via an > oscilloscope. > > To monitor the PRU busy time: > > * set hpg.pru_busy_pin to 128 + the PRU direct pin number > > * configure the selected pin to be a PRU direct output > > By default, the PRU busy pin is enabled and routed to PRU direct > output 0 (hpg.pru_busy_pin = 0x80), so if you're using my universal > overlay and are not otherwise using P9.31, all you have to do is setup > the pin: > > config-pin P9.31 pruout > > ...or for example to use P9.28: > > halcmd setp hpg.pru_busy_pin 0x85 > config-pin P9.28 pruout > > > (Is there either a step by step calculation guide for this. It would be > nice if > > there was a tool similar to the parport configuration tool for the > beaglebone > > PRU configuration. > > Yes it would...feel free to send a pull-request! :) > > > The max velocities don't seem that unreasonable. > > No, it's the very large scale values that are causing problems > (particularly the one that's 75000). That requires 75000 pulses per > second with a maximum velocity = 1.0 (75 KHz), and the stepgen > velocity limit is set to 1.2x that (90 KHz), but the maximum step > frequency when using the PRU defaults is only 50 KHz. If you can > reduce the micro-stepping or otherwise decrease the scale value (while > keeping the machine useful), that would help. > > ...but it should work as-is if you drop the PRU period to 3000 to 5000 > nS, which should be very safe since you're only running 4 stepgen > instances. > > > I tried halfing this variable, > > https://github.com/Workshop88/machinekit/blob/master/ > configs/ARM/BeagleBone/RosettaBoneGecko/RosettaBoneGecko.ini#L101 > > by 1/2 and it seemed that I broke > > That is the wrong place to change anything for the PRU. > > Add "pru_period=5000" to CONFIG= in [PRUCONF] > > https://github.com/Workshop88/machinekit/blob/master/ > configs/ARM/BeagleBone/RosettaBoneGecko/RosettaBoneGecko.ini#L3 > > ...here's an example: > > https://github.com/cdsteinkuehler/machine-configs/blob/master/configs/ > MendelMax/MendelMax.ini#L3 > > -- > 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 a topic in the > Google Groups "Machinekit" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/machinekit/mmbJ_CZUakA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > 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 [email protected]. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
