Yes, but you are doing it.
No I'm not. It's my opinion that these numbers are pointless. I run my loops at 500usec and even that's overkill.
The first time I brought this up was in another thread. I forget the exact wording but the gist of it was; what's the
deal with the likes of OMRON boasting about ridiculously fast loop-rates. I was hoping for you to enlighten me but you
blew me off because it wasn't relevant to the thread.
When I code, I count clock cycles and I optimise (old habits) when I really don't need to. All I did was demonstrate that a $100 off-the-shelf module can cope with this stuff while spending most of its time waiting for time to elapse.
Who's product are you promoting anyway? Galil, Trio, your own?
None. I have my own market and zero competitors. I don't want to be in that business because it would mean solving other
people's problems. I only use the other guys as a reference.
I'm interested in sparking interest in others who are frustrated with the status quo and would like to become more independent.
Take a glance at the issues on this forum....So ridiculous.
I think I already told how my approach has inspired an automotive supplier to migrate from PLCs to Node-Red tablets and low-cost MCUs.
The hardware specs are not an indication what the controller can do. Software is a better indication. Without software the hardware does nothing.
Totally agree.
What is the required bandwidth of the application? That is the spec the must be met. Most big industrial systems only accelerate/decelerate at 5 to Hz.
Almost exactly what I preach except I use 10Hz
Our user programs run synchronously with the scan time so no interrupts are required.
Translation (and I hold my hand-up if I mis-read): User program execution is limited to whatever the loop-rate is set at.
Furthermore, the faster the loop-rate, the fewer clock-cycles available to the user program.
You missed it. I already stated that in addition to the P2, I have four other dual-core RP2040s that run independently but communicate with the P2. Three of the RP2040s have 24 I/Os and the fourth has 16. Furthermore, they each feature a Mikroe Click socket (more than 1000 modules available) to suit special needs.
The fourth RP2040 uses pins to drive a VGA monitor to inform the operator of machine status. In our case, the RP2040s each run PicoMite BASIC and they have on-board code-editing (with color-coded syntax). Plug-in a terminal and the user is able to create/edit and instantly test whatever. No programming licenses, no incompatible protocols, no dongles.
For example; a "Start" signal involves the closing of a n/o contact plus the opening of a n/c contact and this state must persist for 40ms (debounce) to be considered valid. Why tie-up the realtime system with this mundane task. The P2 simply asks if a "Start" command has been received.
The time critical I/O such as position latches, triggers, etc., is handled by one or more the P2's 8 parallel processors. The response is a few tens of nanoseconds.
Others prefer Python or C and so all they need to do is load-up their preference.
Tinine is in a completely different market. It is one we don't wish to enter...so far. Cheap controllers can only be sold to OEMs that use quantities and when they can support the product themselves.
Not in the cheap controller business. Merely sharing my discoveries.
Our competition is Beckhoff, Siemens, Rockwell
Yeah, those are the guys that I replace due to their EOL. Hardware might be found on eBay but then there's the issue of firmware and parameters, etc.
My focus is on resurrecting existing iron that is super-costly to replace but has been relegated to boat-anchor status due to big-name control hardware that no-one can work with.
Mechanical issues, hydraulic issues, pneumatic issues are all easily dealt with. Obsolete control gear is the killer.
All too often, I've been the one guy on someone's plant floor on Turkey-day, cobbling together whatever I found at Radio Shack to try to get a line running. There is no need for this cr@p.
Craig
