True.

My CNC project has steppers for X, Y1, Y2, and Z; with either stepper or DC 
motor for tool. In a 3D printer, the tool is a nozzle size and plastic 
temperature of the additive, also the bed is often heated, but not in my 
case. I have not planned a sheet cutter based on laser, water, sand, etc. I 
have only envisioned milling, drilling, threading, 3D printing, engraving, 
measuring, and may be pick n place. There are limit switches on X, Y and Z 
axes, temperature sensor on print head (and bed).

My project is (cheap) tooth belt drive for X and Y, but lead screw is 
probably better. The steppers are weedy 2A 24V types with micro-stepper 
driver. The DC motor is stupid RPM 200W 30A 7,2V run from 12V with PWM, 
that heats up the bearings used in the spindle, the spindle is a 3mm collet 
type pin vice.

>From my experience, the capes:

   - Stop and safety switch inputs
   - Stepper control with/without driver
   - Motor and positioning loop control and may be motor driver
   - Limit switch inputs
   - DC motor control with/without driver
   - Heater control with/without driver
   - Temperature sensor inputs
   - Broken/Missing tool sensors
   

The BBAI is a little different to other SBC, in that it has DSP cores, GPU 
cores, application cores and controller cores. A glance at the machine kit, 
it expects a vanilla SBC, access to the DSP, controllers and capes is 
through HAL/drivers.

How close to the BBAI and its capes, do you want high voltage, high current 
switching?

A pick n place machine might have camera inputs to identify the PCB, check 
application of solder paste, identify component, orientate component, check 
component placement, check soldering faults, etc. 
It might have 6 axes positioning of camera and/or placement head. Vacuum or 
clamp control, to hold down the PCB and pick up the components. 

Would you use the BBAI DSP for image recognition, its application processor 
and GPU to run application and calculate tool paths, microcontrollers to 
control data interfaces and capes?


On Thursday, 19 March 2020 11:47:03 UTC, justin White wrote:
>
> Wow that has absolutely nothing to do with seeed's cape.
>
> On Wed, Mar 18, 2020, 7:37 PM John Dammeyer <[email protected] 
> <javascript:>> wrote:
>
>> Would someone perhaps be able to describe simply (like MachineKit for 
>> Dummy's) how exactly the step pulse and direction shows up on the Beagle 
>> pin relative to the motion command from a G00 X1.0 where current X position 
>> is 0.0.
>>
>>  
>>
>> Clearly we accelerate and move and then decelerate to arrive at the end 
>> point of 1.0.  I do this in my ELS code inside the interrupt routine 
>> which happens at a 20kHz rate.  If a step is required I set the output 
>> at the beginning of the routine and then clear it at the end after a whole 
>> bunch of other stuff is done.  
>>
>>  
>>
>> Whether to step or not is done by the equivalent of a trajectory planner.  
>> For example in simple terms if the motor could accelerate instantly and 
>> the step rate was 10kHz then every second interrupt the axis is pulsed.  
>> Also 
>> for every pulse the position is incremented if going in the positive 
>> direction.  Decremented if going in the other direction.  When it 
>> matches the end position the stepping is terminated and we have a move to 
>> position.
>>
>>  
>>
>> Inside my ELS interrupt code I do the accel/decel too.  The interrupt 
>> routine changes the number of 20kHz intervals between step rates and also 
>> tracks the half way point.  If we're not up to speed yet but the halfway 
>> point is reached then deceleration is started and by the time the stepping 
>> rate reaches 0 the motor has also reached it's desired position.
>>
>>  
>>
>> Otherwise once the step output pulse rate matches the desired velocity 
>> the acceleration part is terminated and the number of steps it took 
>> recorded, and now a pulse happens every second interrupt (for 10kHz step 
>> rate).  When the destination location minus the time it took to 
>> accelerate is reached deceleration begins.  And since we decelerate at 
>> the same rate as accelerating and we have that same distance to move, once 
>> we reach 0 speed we've also reached the destination.
>>
>>  
>>
>> Now this could all be done outside the interrupt routine in a trajectory 
>> planner.  One could determine that it will take time X to reach either 
>> target speed or midpoint of the distance to move.  Broken into the 20kHz 
>> steps then the information could be fed into a FIFO so no math is done at 
>> all inside the interrupt routine.  It's only task would be to read this 
>> from FIFO one byte during each interrupt and write it to the port.   The 
>> interrupt routine could then run 40kHz and clear the port of step signals 
>> every second pulse.    If there is no motion the FIFO, flagged as empty, 
>> holds the last entry for the port and it's just mirrored out to the port. 
>>  
>>
>>  
>>
>> So how is it done in the Beaglebone with MachineKit.  Is there a 
>> function that reads a FIFO filled by the trajectory planner or is it done 
>> yet some other way?   I would look it up but don't even know where to 
>> start.
>>
>>  
>>
>> Obviously there's probably more going on under the covers to deal with 
>> hard limits.  Seems like soft limits are dealt with before motion starts 
>> with the option to not move because it will exceed machine limits.
>>
>>  
>>
>> Thanks
>> John Dammeyer
>>
>>  
>>
>>  
>>
>>  
>>
>> -- 
>> 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] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/machinekit/023801d5fd7e%242a472570%247ed57050%24%40autoartisans.com
>>  
>> <https://groups.google.com/d/msgid/machinekit/023801d5fd7e%242a472570%247ed57050%24%40autoartisans.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6aa3ef97-5254-490c-9065-e68bed257560%40googlegroups.com.

Reply via email to