Those schematics look surprisingly similar to ladder logic. I always thought that ladder logic for programming PLCs makes absolutely no sense compared to a proper programming language, but now I see that it does make quite a lot of sense if you're trying to get electrical engineers who used to design actual physical logic circuits into programming PLCs.
> The motivation for representing sequential control logic in a ladder diagram was to allow factory engineers and technicians to develop software without additional training to learn a language such as FORTRAN or other general-purpose computer language.
> Ladder logic can be thought of as a rule-based language rather than a procedural language. A "rung" in the ladder represents a rule. When implemented with relays and other electromechanical devices, the various rules execute simultaneously and immediately.
The combination of both statements entertains me, because while defenders of imperative languages might even admit that they are worse languages, they still cling on to the notion that imperative is easier to teach or understand and that other approaches requires genius level intellect. When it's mostly about what you are familiar with that determines what approach feels easy.
(Different approaches still differ in how well they can express or maintain your program whilst making errors harder to make, of course.)
> I see that it does make quite a lot of sense if you're trying to get electrical engineers who used to design actual physical logic circuits into programming PLCs
It was specifically designed for electricians (sparkies), not electrical engineers. And indeed, it’s intuitive with that background. Junior engineers struggle at first, but ladder logic is an elegant language for the problem domain.
I would've liked to see an explanation that includes the weight of water being displaced. That would also explain how a steel ship with an open top is also able to float.
Is this an issue with the price of sugar? From the video, it seems like they have already fermented the beans, turning it into some basic dark chocolate after that shouldn't be too hard especially if you're not after a smooth texture.
Interestingly, the steam engines of the Titanic made use of the vacuum generated by condensing steam to extract additional energy from steam that's below atmospheric pressure.
Do operators currently need to manually control every movement of the arm? I always assumed that such heavy equipment uses inverse kinematics to help the operator.
Not so much these days, but the general idea is correct.
Usually there are joysticks (one per hand) that provide control over one movement per axis. So for example the right hand joystick on a mini-excavator usually controls bucket curl (left/right) and boom movement (forward/back).
Left hand does boom up/down and rotate left/right. There's an ISO standard for this UI.
Old school tractor-loader-backhoe machines (what people in the US call "a backhoe") had one lever per cylinder, so more complicated to control and more
levers. An old-style motor grader is the extreme example of lever confusion[1].
Operation of heavy machines relies (still) on the brain's capability to virtualize the movement of the machine in terms of the body's limbs. That's why
you need some time training to become proficient. After a few hours you just think "I want the bucket over there" and your hands make the necessary movements
without thinking.
There's already lots of automation available on high-end machines such as use of GPS to control cut/fill operations with bulldozers, and laser-transit-based automated dig depth control for excavators.
Often a lever, or joystick motion, per function.
And site plans can be input to bulldozers and excavators, and with precision sensing they do cool things like preventing operator from digging below grade. Those 'sticking pipe' in trenches, and those putting in landfill cells rave about it because it avoids rework. The old guys don't need it, but they are aging out of the workforce.
Here's a modern piece of heavy equipment, a Ponsse tree harvester, with the operator showing how the machine is used.[1]
One big joystick for each hand, and a lot of buttons on each joystick.
The operator is guiding the beast, but once it grabs onto a tree, there's
some automation to cut the tree into preset lengths. Notice how fluid the
movements of the machine are.
It's nowhere near autonomous, but it's several times faster than total manual control would be.
There's no IK because sometimes the operator needs to be very specific about where the "elbow" or "shoulder" ends up, to avoid hitting some other object. So they have manual control over everything.
If you're going to automate the kinematics, then you either need a manual override mode (which the operators will be unskilled with since it's seldom-used), or you need sensors and rules for the machine to know where it's not supposed to be (clearances around wires, other structures, etc) and that needs to be better than human operators currently do.
Those are theoretically possible, sure, but a valve-per-cylinder is really stinkin' reliable.
The wiki.vg website has a list of quite a few server implementations, even some written in Rust! That site also has extensive documentation of the Minecraft protocol if you want to try writing a server or client yourself.
That battery is for load shifting from peak times to off-peak times and also to provide bridging power while other generators start up. If you want reliable purely green power, you need a lot more battery. For longer term storage, pumped hydro seems to be the only option for now.
That image makes me appreciate just how slowly most plants grow and move. Imagining that bundle of dandelions writhing around triggers the same sort of visceral reaction as seeing maggots for me.
If it’s any consolation that picture was probably about a week after treatment, so still quite slow! The entire process takes about two weeks depending on the type of plant.
reply