Very interesting, presumably it can step through pre-programmed sequences of bends setting new XYZ values for each step of the program?
On Sun, 24 Apr 2022 at 18:22, Ted <laser...@gmail.com> wrote: > > Subject: Re: [Emc-users] Variables for instantaneous transit vector > > from python? (long) > > Message-ID: > > <CALQw8iOGM9jTV7Gh8Ps63vA0=_ > arcsedzkudzibbkyu0uln...@mail.gmail.com> > > Content-Type: text/plain; charset="UTF-8" > > > > Hey I won't be much help but I would love to see how you did a break > press > > gui! > > Andrew - I really do need to put together an entry for the wiki on this > - we haven't quite given it the "full wrap" yet; it got the the point of > daily supervised testing but stalled at that point (date: Dec 2018, I > bet you can guess why) - however I did upload a screen cap from it at: > https://pasteboard.co/nyWk9elvzxj7.png if it's of interest. The main > points were to emulate the existing nomenclature of the press, so the > vertical ram is "Y" (not R or X, for instance), and the two back-gauges > (X and Z, also by those names originally) were servo driven. The Ram > itself in this application was hydraulic with a Vickers proportional > valve (0-10v control) and a glass scale attached - so it turned into a > servo axis as well. We initially shied-away from trying to drive the > valve in that tight of a loop, because we thought the system might > cavitate, but it responds really really well that way. Way better than > simply up-fast/down-fast/slam-stop! > > This project had about a dozen different (less than successful) > approaches but the production version uses a more streamlined custom > component that handles only safety and logic rather than motion control. > (Our first attempt was to build a comp with full motion control, but it > turned out to be too jumpy) - so the motion is actually controlled by > triggering a couple of g-code files. Jogging or manual single bends are > straightforward jog implementations, semi-automatic is the daily-use > feature that the operator sets waypoints and times - so we have ngc > files for ram down, ram dwell and ram retract that reflect that. > Although there is a plan for full-auto, we haven't bothered to implement > the fully-auto feature, which due to the change in our comp file got > simplified to just plain old g-code that they would write. We skipped on > that due to operators not being interested in that level of complexity. > They also didn't seem interested in wizards for taking material, > knowledgebases, k-factors, tooling details, and building numbers - they > just wanted to run the ram down to the number they set and keep > repeating. Still a very hands-on type of process for them. > > We took graphic and layout concepts from the original operators of the > machine (it was an Accurpress 25 ton unit with a win98 control), as well > as other shop operators using the current generation control on a larger > unit but intentionally not wanting to copy it verbatim - as it turns out > a number of the operators liked our different layout. > > Ted > > > -- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
