I'd seriously doubt that support for Mesa SPI cards is available in MK considering how far behind Mesa support is but I don't know that for certain. Either way you would be far better served to use the 7C81 which is an rpi specific spi card, with no need for an adapter PCB the rpi just plugs into it. There's also the question of whether the 7i90 supports hm2_rpspi or not. The generic kernel spi driver is hm2_spi which is the one that was around when the 7i90 came out. hm2_rpspi has better real time considerations and is meant for the rpi. The 7C81 cost quite a bit more but a pretty capable all in one board with no need for another daughtercard. You may have to stick with linuxcnc to get the rpi over spi running
On Thursday, March 19, 2020 at 12:33:27 PM UTC-4, dave engvall wrote: > > Hi all, > > I've been waiting for this discussion to segue to the Pi. Indeed the Rpi4B > is a decent jump up in capability. If one drives Mesa or other hardware off > the spi then the ethernet is nicely left open for downloads, etc.With the > -4b you seem to get it all. Speed, communication, display (2), some > flexibility and decent access to Peter's or others boards for step > generation. I suspect it will only be a mater of time before someone mods > the software to use both hdmi ports. The good news I think is that the > technology will just get better. :-) > > My plan is: Rpi4b - 7i90 - 7i33 (2) - sem servo motors but Mesa has lots > of solutions for steppers also. > > Just a heads up; finding connectors that will allow one to directly > connect the spi to the 7i90 is not easy. The plan is to use the osh-park 40 > pin to 26 pin board to as the spi bridge. Just because it is logical > doesn't mean it is possible. Still looking. ( ideas accepted ). > > Comment: long ago (maybe 20 years ago) I acquired the glass scales > before I realized that they were good for position but not so good for > motion. Servo tuning with them is a bear. Not having any experience with > steppers can't comment with any authority but suspect they would be easier > since they are open loop (mostly). > > Gene Heskett and maybe a couple of others are running the Rpi4b under > linuxcnc. Gene's implementation is for steppers. > > Note: these comments are worth about what you paid for them. ;-) > > Hang in there, stay safe! > > Dave > On 3/18/20 5:40 PM, John Dammeyer wrote: > > > > > > *From:* [email protected] <javascript:> [ > mailto:[email protected] <javascript:>] *On Behalf Of *justin White > *Sent:* March-18-20 5:24 PM > *To:* John Dammeyer > *Cc:* Machinekit; [email protected] <javascript:> > *Subject:* Re: [Machinekit] Seeed to design and build Machinekit focused > Cape for BeagleBone Black/AI > > > > Wow that has absolutely nothing to do with seeed's cape. > > Yes it does! My previous posting suggested that a cape by SEED should > include the infrastructure to have a display and function as a standalone > electronic lead screw for a mill. And accept the motion information from > something like a Pi or PC via Ethernet if full CNC was required. > > > > That means the software running on the BBB would not be conventional > MachineKit. In fact the software might be straight C code developed with > the TI IDE as a standalone project with display that can service as a > multi-axis power feed and DRO. Or if could be a subset of MachineKit > without the HDMI interface. > > > > So it could do motion. The idea is that it could also, via Ethernet, > like the MESA 7i92H receive information that would generate the stepping > pulses and feedback the DRO information. > > > > It's time to think outside the box because with the much more powerful Pi4 > coupled to MESA hardware there is no way that SEED or anyone else can > produce something as good. So it has to be something different. > > > > Seriously. Why pay $150 for a full blown BBB Cape that serves as a Break > Out Board and $50 for a BBB that then gives you sub par video compared to a > much faster quad core Pi4 running LinuxCNC and Ethernet to a MESA board > where the total price ends up pretty well the same. > > > > Technologically the BBB is now old. Very old. And it's just plain silly > to continue to try and make it a be all end all. I'd say 99% of the > people I talk to who have CNC are running either MACH or maybe LinuxCNC. > Mostly > they aren't interested in changing. The ones who have mill but not CNC > either want to add power feed and perhaps DRO but again most of them are > not interested in CNC. > > > > So where's the market? It's easy. The DRO and Power feed controller > that can magically turn into a CNC controller. > > > > John Dammeyer > > > > > > 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> > . > > -- > 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/CA%2BQ02MOgrNTwNmP3j8CdCai7Pj7Bm9xVm3eZfhq2AhW2niAuAg%40mail.gmail.com > > <https://groups.google.com/d/msgid/machinekit/CA%2BQ02MOgrNTwNmP3j8CdCai7Pj7Bm9xVm3eZfhq2AhW2niAuAg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- > 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/027301d5fd87%240ea11e30%242be35a90%24%40autoartisans.com > > <https://groups.google.com/d/msgid/machinekit/027301d5fd87%240ea11e30%242be35a90%24%40autoartisans.com?utm_medium=email&utm_source=footer> > . > > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/machinekit/7b59d983-4a06-4929-82c1-5e3701ea56bb%40googlegroups.com.
