Switch to English Language Passer en langue française Omschakelen naar Nederlandse Taal Wechseln Sie zu deutschen Sprache Passa alla lingua italiana
Members: 71,918   Posts: 1,584,730   Online: 773
      
Page 11 of 13 FirstFirst ... 5678910111213 LastLast
Results 101 to 110 of 121
  1. #101
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,341
    Images
    12
    Yes, interference on the power supply line will cause the Arduino or LCD to crash or be corrupted. You must have a clean power supply, completely independent of (or very well isolated from) any large loads that you're switching, otherwise the switch transients will cause problems. This is a huge issue for all-DC systems, e.g. people trying to control DC motors and servos and connecting them to the same DC supply that runs the Arduino itself, but it shouldn't be too much of a problem for AC systems because you have a switching regulator to isolate your arduino from the mains. Some are better than others, of course...

    In your case it sounds like you're getting a big transient off the cooling fan; there's probably something wrong with it if the transient is worse than the enlarger switching. Could probably do with a snubber on the fan terminals.

  2. #102

    Join Date
    Jan 2007
    Location
    Kildare, Ireland
    Shooter
    Multi Format
    Posts
    187
    All true. I did indeed add snubbers to the fan supply, and doing that along with following the guidelines linked in my post means that the problem seems to be gone. I used those optically isolated relays, which although dirt cheap on ebay, at least work as they should for now. The real test will come with time and use....


    Fran

  3. #103
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,341
    Images
    12
    PCBs are sold out, but a new batch of 30 are on their way to me from Hong Kong right now. If you're thinking about building one of these, parts are available!

    Would people (without electronics/soldering skills/tools) be interested in a pre-assembled+tested version? I suspect it'd be on the order of $100 including everything except a case, power supply (phone charger) and mains relay, for which you would use a powerswitchtail or similar.

  4. #104

    Join Date
    Feb 2007
    Location
    Austin, TX
    Shooter
    Med. Format RF
    Posts
    263
    Quote Originally Posted by polyglot View Post
    PCBs are sold out, but a new batch of 30 are on their way to me from Hong Kong right now. If you're thinking about building one of these, parts are available!

    Would people (without electronics/soldering skills/tools) be interested in a pre-assembled+tested version? I suspect it'd be on the order of $100 including everything except a case, power supply (phone charger) and mains relay, for which you would use a powerswitchtail or similar.
    I would strongly consider purchasing a prebuilt unit, I keep telling myself that I will put together this one and even have a PCB but it seems a little out of my scope.

  5. #105
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,341
    Images
    12
    New batch of PCBs are in. $20 shipped anywhere, PM me for paypal details.

  6. #106
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,341
    Images
    12
    So I just wrote an email full of Mouser part numbers to someone and figured it would be best posted here too for anyone doing a build at the moment.

    If you want to turn a safelight off when the enlarger is on, you use a DPDT mechanical relay with 5V coil. Assuming you're buying from Mouser, get 653-G2RL-2-DC5 and wire it like I've shown in the attached scribblings: power supply to the common pins, safelight between the NC (normally connected) pins and enlarger between the NO (normally open) pins; earth always connected to both loads. If buying a relay elsewhere, the important specifications are:
    - 5V coil with about 65 ohms resistance
    - contacts rated for >=8A at >=115VAC (USA) or >=240VAC (elsewhere)
    - DPDT

    Look at page 4 of the datasheet for that relay (link is on Mouser page). From the pinout:
    - timer "OUT" pins connect to pins 1 and 8
    - supply Live connects to pin 3
    - safelight Live connects to pin 2
    - enlarger Live connects to pin 4
    - supply Neutral connects to pin 6
    - safelight Neutral connects to pin 7
    - enlarger Neutral connects to pin 5

    All connections to that relay must be soldered and use mains-rated wiring; I recommend stripping open a 3-pin extension cord and using the 3 wires from inside it.

    Before powering up, make sure that the ground connections are solid:
    - input plug to timer chassis
    - input plug to both output sockets
    - input L/N should show continuity to the safelight L/N

    and make sure there are NO shorts:
    - input L/N to chassis
    - enlarger L/N not showing continuity anywhere.
    - there should be at least 5mm clearance between any mains circuits (L/N lines) and the chassis or any other wiring.

    Grounds are NOT OPTIONAL. Use a metal chassis/case for the timer and always connect it to a grounded supply.

    That will work for enlargers up to about 500W (115V). If yours is bigger, you need a bigger relay.

    Have a look at the attached scan of the PCB that I've marked up. You can leave off the 100n capacitor; it's not actually required for the timer and is on the board only to support other things that the same board is used for. Where there are blue lines on there, put in wire links. The two circled pins are where you connect the foot switch. Use a high quality (Apple/Samsung not generic chinese $5 thing) USB phone charger as the power supply and that means you can leave off all the power supply parts on this board, and don't need a transformer in the box. The pins labelled "OUT" (with red rectangle highlight on scan) are what connects to the relay coil.

    In terms of transistors, any BC546, 547, 548, 549 will be fine. Any version from any manufacturer, with any letters at all after the numbers. For the purposes of this circuit, they're all compatible.

    For resistors, pretty much anything goes. Easiest to obtain will be 1/8W metal-film or 1/4W carbon; for example on Mouser, 71-RN55D-F-1.0K and 71-RN55D-F-6.8K

    For wiring to the foot switch, relay, etc, I recommend buying something like eBay 251661434781 and Mouser 855-M20-9724046 (snap off shorter lengths as required). You'll also want a couple of 855-M20-9774046 (snap-off lengths as required) for the pins that plug into the Arduino and LCD. And you'll want a couple of 855-M20-7821646; one to solder onto the LCD and another for the encoder board; again you just cut it to length with sidecutters (sacrificing one pin with each cut) so that it has the right number of pins; 2 strips of 3 pins are used for the encoder.
    Attached Thumbnails Attached Thumbnails safelight-wiring.jpg   pcb-relay-wiring.jpg  

  7. #107
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,341
    Images
    12
    Beware: Windows Update may kill your f/stop timer or any other Arduino device you may own.

    Short version:
    - most Arduinos use an "FT232" chip to implement their USB port,
    - the FT232 chips are incredibly common and frequently cloned. If you have a generic Chinese Arduino, it will definitely have a clone FT232 chip on it.
    - The clone chips work absolutely fine.
    - FTDI, the manufacturer of the chips, has released a new driver which will deliberately brick (destroy) any clone chip connected to a Windows PC
    - plugging any Arduino into the new Windows driver risks bricking it

    There are ways of unbricking these chips, but it is complicated.

  8. #108
    Dr Croubie's Avatar
    Join Date
    Mar 2013
    Location
    rAdelaide
    Shooter
    Multi Format
    Posts
    1,554
    Images
    2
    Quote Originally Posted by polyglot View Post
    Beware: Windows Update may kill your f/stop timer or any other Arduino device you may own.

    Short version:
    - most Arduinos use an "FT232" chip to implement their USB port,
    - the FT232 chips are incredibly common and frequently cloned. If you have a generic Chinese Arduino, it will definitely have a clone FT232 chip on it.
    - The clone chips work absolutely fine.
    - FTDI, the manufacturer of the chips, has released a new driver which will deliberately brick (destroy) any clone chip connected to a Windows PC
    - plugging any Arduino into the new Windows driver risks bricking it

    There are ways of unbricking these chips, but it is complicated.
    Ouch. I can understand FTDI getting annoyed at people cloning their IP, but for someone who doesn't know if they have a genuine chip or not it's best to stay away from the official drivers, and that's only going to push people into using non-official drivers and bypassing FTDI altogether (I know I would if I used Win).

    Any word yet on this appearing in Linux? I'm using the FTDI module as supplied in the kernel sources, would kernel devs let this auto-brick code through?
    An awful lot of electrons were terribly inconvenienced in the making of this post.

    f/64 and be there.

  9. #109
    polyglot's Avatar
    Join Date
    Jun 2009
    Location
    South Australia
    Shooter
    Medium Format
    Posts
    3,341
    Images
    12
    The linux drivers are open source and not subject to this kind of bullshit. However if you plug an Arduino into windows and it gets bricked (the new drivers reprogram the fake chips with a zero PID so that they can no longer be recognised by the kernel for what they are), it will no longer work on linux either. As an aside, no one copied any FTDI IP, the problem is that they're using FTDI's device identifiers and chip markings on a compatible but completely independent design; it's branding fraud rather than copyright violation.

    The most common reaction I've seen so far is "it's too risky to design FTDI chips into products now" especially considering most small-scale designers contract out PCB assembly to China and do not control their build supply-chain. I expect to see demand for FTDI devices dropping dramatically as they get designed out of stuff. There are functionally-similar alternatives available legitimately for approximately what the cloners charge for fake FT232s.

    The depressing thing is that if Microsoft's USBSER.SYS wasn't completely broken (it doesn't pass their own WHQL testing), all the USB/serial adapters would be running on USB's open specification for serial ports and there would have been no need for FTDI to invent a new protocol and ship a driver and for people to clone that device because the FTDI driver was more stable and usable than the Windows generic-serial driver. Goes without saying that the USB/serial driver in linux works fine but that because of MS's fuckup, there is no credible supply of generic USB/serial adapter chips to use with that working driver.

    It will be Interesting Times when the first piece of medical equipment gets bricked and the hospital's lawyers start asking questions. Quietly sabotaging end-user equipment is not going to lead to sunshine and happiness for anyone. Putting up a "this is a fake device and I won't talk to it" warning would have (I think) done everything that FTDI needed - get all the fake chips out of the supply pipeline - without enraging end-users. And it would have pressured end-users to pressure equipment manufacturers to fix/upgrade their products, not just randomly broken a whole bunch of stuff.
    Last edited by polyglot; 10-23-2014 at 06:37 PM. Click to view previous post history.

  10. #110
    Dr Croubie's Avatar
    Join Date
    Mar 2013
    Location
    rAdelaide
    Shooter
    Multi Format
    Posts
    1,554
    Images
    2
    That's good to know, if it's completely open source then I can't imagine devs letting that through if they know about it. I was wondering if the kernel-driver code was something supplied by FTDI themselves, or even as a binary-blob, that it may somehow work its way in. Another good reason to not use binary-blobs, you never know what's in there.

    So now the next question is (from someone who doesn't use windows much), can windows users get around this?

    Can I just *not* install the new updated bricking driver? I know updates can be hidden and such, presumably if I've got the driver already I just have to 'hide' the update and keep using the old one, correct? (obviously, one must be adept enough and have settings not on 'update automatically without telling me')

    But if I'm putting together a new system as of today, it will automatically download the new bricking driver and there's nothing I can do about it? Or if I find an old driver (installed manually, not from the windows catalogue) then hide the new one in windows update as above? Or is there an unofficial 3rd-party non-bricking driver, that I can install that will stop the 'official' bricking driver from being installed?


    Interesting what you say about hospitals and lawsuits, if something bricks and someone gets killed, it's gonna make a lot of lawyers rich going back up the pipeline to see who knowingly (or more likely unknowingly) used the wrong chip. A lot more people than the end-user may have been duped along the way.

    I'm wondering about the usbser.sys bit too. At one end of the spectrum there are those who cloned the chip entirely to purposefully counterfeit and deceive. But at the other end of the spectrum, I wonder if there are those who purposefully and legally cleanroomed starting with the driver, or even invented their own hardware but wanted to use a working driver, who found that they had to emulate certain protocols to use said driver and are now finding themselves also victims of the brick?
    An awful lot of electrons were terribly inconvenienced in the making of this post.

    f/64 and be there.



 

APUG PARTNERS EQUALLY FUNDING OUR COMMUNITY:



Contact Us  |  Support Us!  |  Advertise  |  Site Terms  |  Archive  —   Search  |  Mobile Device Access  |  RSS  |  Facebook  |  Linkedin