[GreenKeys] M15 Restoration -- Type Bar Basket

[E.]

Sorry, I misread what you typed - I’m a bad multitasker ;p .  Ignore me ;) … but do oil ;o .


> On Feb 3, 2021, at 1:30 pm, Paul Birkel <pbirkel at gmail.com> wrote:
> 
> I’m in the process of bringing an M15 back into service after a long period of storage.  This is the unit that was previously used by a MARS member that I’ve mentioned in previous queries.  The dash pot is now unfrozen and I’ve been able to set up a local loop.  I’m using a REC11, so plenty of loop power; the loop is currently running at 62 mA.  The resulting behavior is not yet explicable.  As this is the first green keys “recovery” that I’ve attempted I can use a bit of guidance!
>  
> The general behavior is that the selector unit and vanes appear to be responding correctly to the keyboard.  FIGS and LTRS shift/unshift the type bar basket properly (controlled by the bottom vane) and the (FIGS) BELL key works.  Other keys work, but with sometimes incorrect results (although in most cases given the lack of printing it’s hard to discern beyond obvious consequences like a SPACE resulting in a CAR RET).  The principal behaviors are that:
>  
> 1.     No type bar is ever triggered, nor does the ribbon advance.  The type bars are all freely moveable.
> 
>  
> 
> 2.     Key presses appear to advance the type bar basket double; 38 key-presses advance the basket across the full width of the platen and then further key-presses have no effect.
> 
>  
> 3.     CAR RET causes either a full return, or a partial return to approx.. the 10-char position (in which case a second CAR RET returns the basket to full-left).  It’s always one or the other.
> 
>  
> 4.     LINE FEED usually works, but not always.
> 
>  
> I notice that the PULL BAR BAIL floats forwards-and-backwards rather than being held firmly against the front PRINTING BAIL BLADE.  This doesn’t seem right to me.  Perhaps I have a lost or incorrectly positioned spring somewhere?
>  
> The PULL BAR BAIL behavior, what appears to be double-advance per key-press, and the lack of ever triggering any type bar, seem to me to be the key anomalous behaviors.
>  
> I can imagine that there may be a timing problem (or perhaps related lubrication problem affecting vane control) resulting in erratic behavior on a per-key basis (even the space is erratic, sometimes causing a CAR RET), but I’d like to first get “basic operations” functional before probing further.
>  
> I have not at this point attempted to clean and (re)lubricate any mechanisms beyond the dash pot.  I absolutely want to avoid major disassembly, unless I have no other option.  I don’t trust myself to get it reassembled and adjusted properly afterwards!  I do intend to go over all of the lubrication points once I’m closer to working order.
>  
> Do I need remove the type-bar carriage, invert, and check/lubricate everything there before proceeding further?  I don’t think that would affect the double-advance per key-press behavior, but I have much to learn.
>  
> I do note that it seems as of the motor generates a lot of ozone.  But it sounds completely normal to me; hums right along.
>  
> Your thoughts?  I’ll keep studying TM11-2215 …
>  
> Thank you,
> paul
>  
>  
> ______________________________________________________________
> GreenKeys mailing list
> Home: http://mailman.qth.net/mailman/listinfo/greenkeys
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:GreenKeys at mailman.qth.net
> 
>>>> Jordan Spencer Cunningham's GreenKeys Search Tool: https://teletype.net/gksearch
>>>> 2002-to-present greenkeys archive: http://mailman.qth.net/pipermail/greenkeys/
>>>> 1998-to-2001 greenkeys archive: http://mailman.qth.net/archive/greenkeys/greenkeys.html
>>>> Randy Guttery's 2001-to-2009 GreenKeys Search Tool: http://comcents.com/tty/greenkeyssearch.html
> 
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> Message delivered to hanyou at xsmail.com