Just a shot here cuz I don't use a BB, or MK much, or charge pumps and I
haven't written a hal file in a year lol......

Anyway if I know the purpose of a watchdog timer and the issue you have is
trying to generate reliable pulses from a hal software component running on
a servo thread? Why not use the PRU pwm or step module to generate pulses
at a frequency to an output pin through your E-Stop circuit and then feed
it back to a PRU encoder pin. You can then arbitrarily use the encoder in
"counter-mode=1" to measure the PWM pin as a velocity and use a software
component like "near" or something to monitor that velocity, near will go
false if the velocity is out of range....i.e., the pulses stopped. This way
the PRU is making pulses, the PRU is counting pulses and the servo-thread
is only limiting the sample rate at which it checks the velocity, you
aren't making or counting pulses in the servo-thread.

Just an idea, not something I've tried

On Tue, Apr 13, 2021 at 12:56 PM John Dammeyer <jo...@autoartisans.com>
wrote:

> Just an update.  I have a 501.9 Hz square wave now coming out DB25-17.
> The simple answer was that I needed to change to
>
> addf      charge_pump.0       servo-thread
>
> The .0 was the issue.
>
> The next issue, and I'm not sure how to get around this is the servo
> thread is too slow and doing something like this:
> loadrt threads name1= fast-thread period1=100000
>
> is not allowed. Probably because
> loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD
> num_joints=[TRAJ]AXES tp=tp kins=trivkins
>
> loads 'motmod' which does what 'threads' does.
>
> I can try the standard parallel port generated version like:
> loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD
> servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES
>
> But I'll have to dig deeper to see why that may or may not work.  Unless
> someone has a better suggestion like doing it the way the MESA does with an
> extra step/dir interface.
>
> Next part is I also want 1kHz PWM.  The MESA does this with hardware
> again. Can the BBB can do it with the PRU?  If not it will have to also be
> done with a base thread of about 10KHz.
>
> John
>
>
>
> > -----Original Message-----
> > From: machinekit@googlegroups.com [mailto:machinekit@googlegroups.com]
> On Behalf Of John Dammeyer
> > Sent: April-12-21 8:52 PM
> > To: 'Machinekit'
> > Subject: [Machinekit] BBB and charge pump
> >
> > I'm using the Xylotex DB25 cape for the BBB.  I've been trying to add
> the charge pump component without much luck.
> > In the HAL file I can do a
> > loadrt charge_pump
> > but an
> > addf charge_pump
> > fails with
> > function 'charge_pump' not found.
> >
> > If I leave that out and run MachineKit on the Beagle I do see
> > charge-pump.0.enable
> > charge-pump.0.out
> > charge-pump.0.out-2
> > charge-pump.0.out-4
> > charge-pump.0.func.time
> > charge-pump.0.func.tmax
> > charge-pump.0.func.tmax-inc
> >
> > But since the this HAL file only has a servo thread and no base thread
> is there a way to get this to work?
> >
> > Ultimately I want the ChargePump output on DB25-17 working in the same
> way I have the PC with MESA 7i92H
> > # DB25-10 actvive low ESTOP signal mapped to 7i92 pin 13
> > # Pin#  I/O   Pri. func    Sec. func       Chan      Pin func        Pin
> Dir
> > # 10     13   IOPort       QCount           0        Quad-A
> (In)             estop-external-in (input)
> >
> > # MESA 7i92H P2 connections mapped to estop-external-in
> > net estop-external-in <= hm2_7i92.0.gpio.013.in_not
> >
> > # Stepper #4 is the charge pump on the MESA card and is enabled with the
> estop-external -in
> > net estop-external-in => hm2_7i92.0.stepgen.04.enable
> >
> > which is output on DB25-17 from the MESA pin 7.
> > # 17      7   IOPort       StepGen          4        Step/Table1
>  (Out)            Charge Pump frequency (output)
> >
> >
> > --
> > 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.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/machinekit/0a0a01d73018%245f04d6e0%241d0e84a0%24%40autoartisans.com
> .
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/0a9d01d73085%24e9fe9c00%24bdfbd400%24%40autoartisans.com
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CA%2BQ02MO%2B2s2tDjv%3Dg86xj8DDtwtJf3jc_rMV0fPmq%3DYjs_tfVQ%40mail.gmail.com.

Reply via email to