Metal Type: Home | Library | Forum | Free Ads | Store

Author Topic: Monotype Composition Caster Interface.  (Read 9630 times)

0 Members and 1 Guest are viewing this topic.

John Cornelisse

  • Moderator
  • *****
  • Posts: 131
  • 31/10/2014
Re: Monotype Composition Caster Interface.
« Reply #15 on: November 09, 2015, 02:23:01 PM »
To make it even more interesting, it is also possible to separate a keyboard papertower from the keyboard it s on.

The valves in it, operating the punches, these can be activated by electronic magnets.

And those magnets are a lot cheaper than electronical valves for compressed air.

In this way it is possible to punch the ribbons for composition, and avoid the timeconsuming typing on a keyboard.

The composition caster will operate as before with the paper ribbons, and might be a good idea for all people who love tradition.

Another advantage is the fact that you can type ribbons for any font possible, without the need of all the keybanks and other equipment Monotype delivered for the keyboards.

Photo's of it I will publish within a few days.

aelorenzo76

  • Ex Tea Boy
  • **
  • Posts: 9
  • 08/10/2012
Re: Monotype Composition Caster Interface.
« Reply #16 on: November 12, 2015, 05:20:57 PM »
Hi John,

I am exploring that way too. It is "easier" and a more natural way to replace the composition keyboard.

I would be quite useful for me if you could share your findings here.

I will do the same.

John Cornelisse

  • Moderator
  • *****
  • Posts: 131
  • 31/10/2014
Re: Monotype Composition Caster Interface.
« Reply #17 on: November 13, 2015, 10:01:34 AM »
A prototype is built here in Lodz.

Controlling the caster can be done with 31 valves, the ribbon has only 31 positions for code\ing. The code can be stored in 4 bytes.

....

Using the keyboard paper tower, you need to remember that this devise is a balance machine:

A code line is only made, when at least TWO punches are activated.

ZERO punches is also a possible code: actually it means: O-15

The O and the 15 punch will be raised, but they don't produce a hole in the ribbon, just an empty line.

Using electonical valves, this can be solved by splitting the air of the first bit, and directing it to the punches for O and 15.

For the keyboard you need to count the bits,

when total bits is equal or smaller than one: than bit zero is activated, however this signal need to activate two coils.

another solution possible, is no counting at all, but activating bit zero with every stroke.





John Cornelisse

  • Moderator
  • *****
  • Posts: 131
  • 31/10/2014
Re: Monotype Composition Caster Interface.
« Reply #18 on: November 16, 2015, 03:57:44 PM »
As it looks now to me, using solonoids to trip the monotype valves would not be a very good idea at all.

these solonoids are not meant to make any force at all, and besides that they would not have a livespan langer than 100.000 cycles.


Within a automation environment, they sure would last not long enough, and do you want to replace them every month ? or even earlier,

In this way they would be a lot more expensive than the Matrix valves

And the 4 matrix blocks at my home they already function more than a decade.

Christophe Slychan

  • Journeyman
  • ****
  • Posts: 48
  • Monotype Geek
  • 26/01/2016
    • rpi2caster blog
Re: Monotype Composition Caster Interface.
« Reply #19 on: January 26, 2016, 11:50:31 AM »
Hello and welcome! I just registered, after the registration errors John reported were taken care of.

First a bit about myself: I work for the Book Art Museum in Lodz, Poland, I'm John's apprentice and friend. He taught me quite a lot about working on Monotype composition caster and super caster - but I think I know just 1/10 of what he does :).
Actually I'm the only person who can run the composition caster here... and one of three people who work on the super caster. The others are Paweł Tryzno (museum's owner and master craftsman) and Aleksandra Ilkowska (an art student who does a lot of hand composition and wanted to learn casting her own type). We have quite a few sets of Monotype display matrices inherited from the defunct Warsaw Type Foundry, and quarter a million matrices for Foucher or Künstermann casters... which we can't use without operational casters or attachment for Monotype machines. But this will surely change.

As the device's builder, I can tell you something more about it...
When I first came to out museum back in February 2014, Paweł gave me a tour, showed me all the machines etc., and one of the things I saw was a metal/wooden stand with a strange device attached to it... I got momentarily intrigued: "What is this?". It was a keyboard's perforator, waiting to be connected to a set of valves controlled by electronics and computer.
Paweł then told me about John, his first (or maybe second?) electronic control device, and I knew that it was a project for me... I got in touch with John, exchanged lots of e-mail, built a first prototype controller without valves yet (will tell you about it later) and three months later I went to John's atelier/home in the southern Netherlands. He taught me the basics of composition caster - and I didn't even touch the super caster before, so it was all new to me. He showed me his interface and software, which was a bit too outdated to me. I'm a modern electronics type: Arduino, Raspberry Pi, embedded systems, networking, open-source software - that kind of stuff. Parallel or serial ports, outdated software, controlling the machine from specific devices etc. is not for me. My way was clearly different from John's, and we both have our opinions...

I also did some research about other computer-control projects, like Harry Macintosh or Bill Welliver's ones, or even the old Monotype computer-aided typesetting that used a traditional ribbon as the data carrier. Not much was known about this, but it was mostly meant for Monophoto and is still used by Parnassia in Vättis with an old Z80 computer. Direct control attachments are much more modern. Why didn't Monotype come up with an idea like this? I don't know.

As for my device, I drew conclusions from what I saw earlier and came up with a few design tenets:
-as simple as possible (wide-spread platform with a custom peripheral with few easy to get integrated circuits),
-free and open-source (no dependence on any proprietary hardware, standards/protocols or software),
-networked rather than tethered (control from any device connected to a local network, be it a PC, tablet, smartphone etc. with no need to install any additional software on your device - a web browser should be all you need).
I built the first prototype in March 2014. It was all soldered by me, the technology was well-suited for prototyping (through-hole mount on a perforated circuit board), used the now-outdated Raspberry Pi model B. I started developping the software without any prior knowledge of programming, the outputs control worked nicely from the beginning. The proof of concept worked and in December we bought a set of Matrix 8-way valves for our museum, making it possible to do tests/development with the actual caster. I also did a lot of casting demonstrations for visitors (the first one in May 2015, and the first thing to cast was a hand-coded "Hello World! - the classic phrase every programmer knows). We rarely get any guests, but when they come, I'm more than happy to show them the old machine controlled by the modern tech.
Actually, I could say that these typecasters were "numerically controlled" (by what was essentially a 31-bit perforated paper tape, made with a special "computer" i.e. Monotype keyboard) - and I, as well as Henry, John or Bill, made it a CNC typecaster - "computer numerically controlled"... :)
With the prototype ready, tested and working, I began my slow work to commercialize the project. This was facilitated by the Raspberry Pi model B+ announced in 2014 - its PCB design was much better, with connectors nicely aligned to the edges, with four mounting holes in a rectangular pattern, and what was most important, with a "HAT" (Hardware Attached on Top) i.e. extension boards standard. Simple, compact, nice. I had some trouble designing the PCB (it was my second design, and my first double-sided with surface-mount components), but after finishing I ordered a bunch of them and went to John's place again. John has also ordered two Hammond HM-1550Z139 enclosures (ca. 160x160mm) from Conrad Electronics, and we bought five adjustable switching-mode DC/DC converter modules to provide power for the Raspberries. The circuit boards arrived a few weeks later and we started building the first two devices, one for John and the other for Han Boordman at Heavy Metal Letterpress near Groningen. We had to order the parts (actually, that was the easy part - a company from my city called "Transfer Multisort Elektronik" or TME is a major worldwide electronics parts dealer, I knew my way around their website, and the shipping costs were as low as 10 euro, so we gave it a go), find a CNC-machining workshop to have the enclosures made (and had some fun with incompatible file formats, designing everything anew...), design and order mechanical parts, buy pneumatic parts, then finally put that together. In the meantime we were restoring the compressed air tank, and John described it in the other thread. Surprisingly, some logistics turned out much harder in the Netherlands than here, where I have a pneumatic parts store and an electronic parts store within a kilometer or so from my museum...
After we built two devices which I call MkI, we had some problems with adjusting the cycle sensor because of the sideways movement of air bar clamp. As the device weighs 1.5 ... 2kg, attaching it to the paper tower by means of a clamp for the connection block sometimes led to it sliding down, cutting the air off... and made it harder to install it. We decided to separate the clamp and sensor from the electronics/pneumatics part. The first ideas were to hang the electronics on ropes (which I found unacceptable - no one knows how high the workplace will be; it may be 2m as well as 4m or more, like in Andreas Schweizer's place or Tipoteca Italiana), then John came up with his own idea of using two prongs out of a steel flat bar to put the thing on the paper tower, and I came up with using two 1" plumbing pipe clamps attached to the takeup spool and a rubber block abuting on the paper tower's back wall to prevent the box from rotating. This would be used in the next iteration, "MkII".
We modified John's MkI device so that it has a disconnectable sensor (in the original design it was integrated). What is more, the new sensor is no longer a visible-light LED and phototransistor in separate holders - it's an integrated IR LED+phototransistor, much smaller and more precise. It's controlled by a metal disc with a slot (rotate it to adjust the "air on" starting/stopping phase), attached to a lever actuated by the original air bar clamp.
Right now I'm finishing the MkII for our museum. The box is bigger (Hammond HM-1550H aluminum enclosure, 222x146mm, actually cheaper than HM-1550Z139...), attaches to the paper tower using the takeup spool, the air connection block is separate (with an integrated machine cycle sensor). I need to buy some LEDs and will get the device ready in a few days.

In the meantime, I'm working on the software... This is a lot harder than the hardware part (pardon my pun). I'm a beginner developer (although with some background in a dev team - software testing, precisely) and the learning curve is steep. To make it easier, I decided to code in Python - very versatile, widespread, with native support for Unicode (I'm Polish, and I know something about different character encodings ;)), multi-paradigm (you want procedural, structural, functional or object-oriented programming, or a mix of those? Python won't stand in your way), with a vast standard library and even more in additional libraries. Easier to learn than C, unless you need to write low-level hardware control routines or work with real-time applications (microsecond precision), where the latter is clearly superior. The more I learn, the easier it gets... I also keep making and correcting mistakes. If I wrote it in C like John did, it would get even more frustrating.
The code is at https://github.com/elegantandrogyne/rpi2caster and the hardware documentation is at https://github.com/elegantandrogyne/rpi2caster-doc-hardware
Right now it has a text user interface. You need to connect to the device and enter commands from the keyboard. You don't have to use any terminal software because a program called "shellinabox" runs on the controller's Raspberry and gives you access to its command line via web browser. But command-line interface is a bit unfriendly for non-geeks... so ultimately, it'll be a proper web app.
I make a lot of changes in what I've written to date, because as I learn programming, I keep seeing a better way to do one thing or the other... Without changing the existing codebase, you just add new functions/statements/etc. and after some time the code grows too much without doing more, and becomes hard or impossible to understand and maintain.
I think that if I talked with experienced developers, I could learn tons about doing things better and simpler, about design patterns and anti-patterns, industry standards (I didn't keep to PEP-8 at the beginning), automated unit and acceptance testing etc. Still a long way to go, but very rewarding.

PS. About the perforator:
I came up with the idea of using solenoids to control the keyboard's perforators because mechanical control would be cheaper than pneumatic. After all, the valves were already there, actuated by levers in the keyboard's base...
But after doing some research on compact solenoids (ca. 8x10mm footprint) - it turned out not viable. No one had solenoids cheap enough. And the durability problem may be a thing, so we didn't want to go on with this plan and I'll use the solenoid valves for the perforator.
Since I've got the separate electronics for the thing (my first prototype with some modifications), I'd like it to be a whole different thing than the caster controller, with its own valves.

There's some theory about solenoid valves. Not all of them will work with our project.
The first thing is: what type of valves we have? Some common options are:
2/2 - simple valve, 2 ports, 2 positions: on or off,
3/2 - 3 ports (air supply, output and exhaust), 2 positions: a single output connected either to air supply or exhaust to drop the pressure after turning the valve off
5/2 - 5 ports (air supply, two outputs, two exhausts) and 2 positions: output 1 conected to supply and output 2 connected to exhaust 2, or output 1 connected to exhaust 1 and output 2 connected to supply,
5/3 - 5 ports, 3 positions: two like the 5/2 valve has, plus an additional middle position, where the air flow is blocked or both inputs are vented. These valves are controlled via two separate coils - one for position 1 and the other for position 2. When no coil is actuated, the valve is in the middle position 2.

Applications:
3/2 is usually used with single-acting pneumatic cylinders (input on one side of the piston - like the air pins on the composition caster; the piston moves forwards when pressure is applied, and returns under external force, when no air is applied).
5/2 or 5/3 are used with double-acting cylinders (with two chambers on both sides of the piston, one air input for forwards motion and the other air input for piston return).
The valves can be normally-closed (with current off, no air flows or the output is connected to exhaust) or normally open (air flows from supply to output when the valve is off).

Because size is less critical here (lots of place inside the box), I can use larger valve islands, like Festo CPV-10 or CPV-14.
They can be had secondhand for a few hundreds of euros and are totally modular. You can get 2, 4, 6 or 8 valve modules of different functions, denoted by letter on the module's face.
There are different baseplates, sideblocks and connection plates (for individual valve controls via a D-SUB connector, or several industry-standard buses, used mostly with PLC controllers). Easy to get confused...
What I need is two valve islands of 8 channels each, populated with "C" valves i.e. double 3/2 valves, with a connection plate for 25-pin D-SUB. And the sideblocks MUST have separate pilot and main ports, since the keyboard operates at 1bar (15psi), and these valves need min. 2bar pressure on the pilot input to open.
"10 most common mistakes made by beginner programmers: missing semicolon, undeclared variable and an off-by-one error."
Technical specialist at Book Art Museum, Lodz, Poland
http://book.art.pl/index.php/en/

Christophe Slychan

  • Journeyman
  • ****
  • Posts: 48
  • Monotype Geek
  • 26/01/2016
    • rpi2caster blog
Re: Monotype Composition Caster Interface.
« Reply #20 on: March 21, 2016, 01:29:21 PM »
Some pics of the production MkII model at the Book Art Museum:








I have an idea for improving the air connection block, so that all tubes are connected on the bottom side. The block could be made of aluminum with screw-in tubes.
The original block from Tjitze Mast had 4mm O.D. brass tubes, but it was a bit too large to put on the 2.5mm I.D. plastic hose; I decided to cut off the brass tubes, drill the holes and solder 31 pieces of thinner copper tube (3mm O.D.) in. Unfortunately, I drilled too far, making leakages between adjacent tubes - but after filling the spaces with epoxy resin, everything works great.

Work is going nicely, I'm developing the casting and typesetting software. I'm very happy to show computer-controlled typecasting to any visitors, and they are always impressed :).
"10 most common mistakes made by beginner programmers: missing semicolon, undeclared variable and an off-by-one error."
Technical specialist at Book Art Museum, Lodz, Poland
http://book.art.pl/index.php/en/

Christophe Slychan

  • Journeyman
  • ****
  • Posts: 48
  • Monotype Geek
  • 26/01/2016
    • rpi2caster blog
Re: Monotype Composition Caster Interface.
« Reply #21 on: May 07, 2016, 10:25:25 AM »
Who would have thought that I'd make old and new tech work together once more...
John's old interface is controlled via antique parallel port. You don't see it on most modern PCs, although there are some exceptions.
Some laptops, like dual-core IBM or Lenovo Thinkpads, still have it - accessible on a docking station. So, why not try to make that work?
Having a docking station and a Thinkpad T61, I decided to try.

The T61 had Linux Mint 17.3 "Rosa" installed on it. It was quite outdated though, and I had some problems with initializing the parallel port. It may be because of the kernel - 3.19.
So, I installed Debian stretch (current testing release) and it worked. I could talk to the parallel port. What is more, the operating system takes care of finding the proper port address just fine, and I don't have to do it in my software.

After some reverse-engineering and analysing, I managed to talk to the old John's interface. It didn't cast proper codes the first time, but it's working nicely after some dabbling with code.
"10 most common mistakes made by beginner programmers: missing semicolon, undeclared variable and an off-by-one error."
Technical specialist at Book Art Museum, Lodz, Poland
http://book.art.pl/index.php/en/