Mini BNC jack faceplate nut tool for IMS3000

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Marcel Birgelen
    Film God
    • Jan 2020
    • 3619
    • Maastricht, NL

    #16
    dolby-ims3000.png
    They should've outsourced their design to some Swedish Meatball peddler.

    Comment

    • Harold Hallikainen
      Film God
      • Jan 2020
      • 1073
      • Tucson AZ

      #17
      That is GREAT! I like the 50 cups of coffee and no books!

      On no books, I am working on integrating a WiFi module into this project: https://w6iwi.org/rtty/DspTU3/ . I was getting buffer overrun errors in the library code from Microchip. So, I copied and pasted the error message into Google AI. It pointed out that the library code version I was using did not support the later firmware in the WiFi module. It told me where to get the correct code. Of course, the compiler then spewed out errors. I copied and pasted each one back into Google, and it came back with what needed to change in the code and why. There is no way I'd know about all the different code versions and the details of getting this to work. But AI know. I'm amazed... And it did not take 50 cups of coffee!

      Comment

      • Leo Enticknap
        Film God
        • Jan 2020
        • 3576
        • Loma Linda, CA

        #18
        This has basically been my experience when using Claude to create Q-Sys plugins to control devices for which none exists and I couldn't justify the time input needed to create a block controller script for one from scratch using the API. I upload the API document into Claude, it gives me a .qplug file, I put it into a design and either emulate or run live (if I have access to the core at the time), it borks out with errors, I screenshot the debug window into Claude, it creates a new version, I try that, rinse and repeat five or six times, and I end up with something pretty solid in 2-3 hours, that would have taken a day or two doing it the old fashioned way. As for the Swedish meatball retailer...

        image.png​

        This appeared in the papers in the aftermath of the infamous North London "Ikea riot" of 2005.

        Thankfully, my local branch in West Covina, CA, is far more civilized. The scary thing is that once inside, the only clue that you're in California and not in the Ikea that opened while I was a teenager in Croydon, England, a few miles from where I lived, is that the price tags have dollar rather than pound signs in front of them. In all other respects, the stores are pretty much an exact replica of each other. When she visits, the Covina store even accepts my mother's Ikea loyalty program card, issued by the Croydon one, for free cups of coffee (though I don't think she's ever needed as many as 50)!

        Comment

        • Steve Guttag
          Film God
          • Jan 2020
          • 3777
          • Annapolis, MD

          #19
          While I've used AI to help me with some LUA, I have not outright had it write something for me. But I see that coming. A concern of mine is support. If it makes it through preliminary checks but on the 3rd install it reveals a problem, how fast will Claude debug the problem correctly? If it does, will it create a new problem? You are, sort of, at the mercy of the machine to be all of the brains of the design. Don't get me wrong, I hate debugging as much as I don't get a thrill from coding/block controllering. I do just want the end-result package. So, things like Claude definitely seem like a good solution.

          I wonder if it will replace manual creation for even simple things too. There are some recent things I've made to address a particular issue. I had a projector that would "undertemp" for no reason and the only way out of it was rebooting. I could set up a Q-SYS monitor for the condition and be proactive about it. Most of the time, it would show itself on boot up, which was nice. Would it be faster to try and explain what I wanted to Claude or was it faster to just create the thing myself? The other part was, due to how Q-SYS lets you work on scripting during run-time...I, quickly defined the I/O I thought I needed before the start of the day and then "wrote" the block controller while it was live and enabled it once I was satisfied it did what I wanted. Note, the problem was solved on a TRP->SST swap...so whatever the errant thermocouple was, it left with the old light engine and/or FMCB.

          Comment

          • Marcel Birgelen
            Film God
            • Jan 2020
            • 3619
            • Maastricht, NL

            #20
            Originally posted by Harold Hallikainen
            That is GREAT! I like the 50 cups of coffee and no books!

            On no books, I am working on integrating a WiFi module into this project: https://w6iwi.org/rtty/DspTU3/ . I was getting buffer overrun errors in the library code from Microchip. So, I copied and pasted the error message into Google AI. It pointed out that the library code version I was using did not support the later firmware in the WiFi module. It told me where to get the correct code. Of course, the compiler then spewed out errors. I copied and pasted each one back into Google, and it came back with what needed to change in the code and why. There is no way I'd know about all the different code versions and the details of getting this to work. But AI know. I'm amazed... And it did not take 50 cups of coffee!
            A wifi module for an RTTY terminal sounds oddly paradoxical, like a PDP11 booting from an SSD.

            But the process you describe sounds only too familiar, but already a bit like yesterday . Nowadays, I feel more like I'm herding AI agents rather than that I'm actually contributing anything useful to the code that's being written... Yes, do it... No, is no, even after trying to refactor that a 3rd time... Sorry, TL;DR, do what you think is good, go all yolo... (me after the 4th time...)

            Originally posted by Leo Enticknap
            Thankfully, my local branch in West Covina, CA, is far more civilized. The scary thing is that once inside, the only clue that you're in California and not in the Ikea that opened while I was a teenager in Croydon, England, a few miles from where I lived, is that the price tags have dollar rather than pound signs in front of them. In all other respects, the stores are pretty much an exact replica of each other. When she visits, the Covina store even accepts my mother's Ikea loyalty program card, issued by the Croydon one, for free cups of coffee (though I don't think she's ever needed as many as 50)!
            I guess you're describing the reasons why I both hate and admire IKEA. They somehow have achieved that what many others are trying to but pertinently fail at. IKEA is more standardized than McDonald's or Burger King. They also tend to own everything relevant in their supply chain and optimize everything to the bone. They're more Ryanair than Ryanair... (for everybody who's had the "pleasure" of flying with them: It's like Spirit Airlines, but the flight will actually depart (they're also currently not bankrupt) and most likely even on-time, but you will feel slightly abused after the experience, a bit like visiting an IKEA store on a busy Saturday afternoon...)

            Originally posted by Steve Guttag
            While I've used AI to help me with some LUA, I have not outright had it write something for me. But I see that coming. A concern of mine is support. If it makes it through preliminary checks but on the 3rd install it reveals a problem, how fast will Claude debug the problem correctly? If it does, will it create a new problem? You are, sort of, at the mercy of the machine to be all of the brains of the design. Don't get me wrong, I hate debugging as much as I don't get a thrill from coding/block controllering. I do just want the end-result package. So, things like Claude definitely seem like a good solution.
            We've been using Claude, OpenAI and have even trained our own models, some actually completely from scratch.

            With everything, it's good to know what the limitations are and many of those limitations you'll only experience by doing. What we've found is that those models CAN be very good at diagnosing problems, as long as they understand the context in which they're operating and as long as the "harness" around those models prevents them from "doing the wrong things".

            That's also how Claude Code can be pretty successful, even at pretty large development tasks: The model itself obviously needs a sound baseline, but they've built a harness around the model that keeps it, mostly, on track.

            I've both been frustrated and blown away by what modern LLMs can and cannot do. But the only thing that really matters: in the bottom line, it was a positive win for us, as it allows me to do stuff I wasn't able to do before. I now have code monkeys that produce like 10 FTE worth of code at a sub 1 FTE cost and they work day and night. Are they perfect? No, far from, but bottom-line those code monkeys living on Red Bull and coffee wouldn't perform any better or worse than those living on GPUs and kWhs..
            Last edited by Marcel Birgelen; 05-26-2026, 06:35 AM.

            Comment

            • Magnus Eriksson
              Film Handler
              • May 2020
              • 58
              • Hagersten, Stockholm, Sweden

              #21
              IMG_4369.jpg
              This week I moved an IMS3000 from a dead S2 Christie to a new S4 Barco. New faceplate with a small plastic bag with:
              Hex nuts for the BNC:s. Good
              Slotted screws for the projector. Wtf

              Comment

              • Steve Guttag
                Film God
                • Jan 2020
                • 3777
                • Annapolis, MD

                #22
                Yeah...that is BS, in my opinion. Barco, historically, used philips screws but has in recent years standardized on Torx screws (T10 for that one). I prefer Torx myself. They don't slip/cam out and you don't gouge the faceplate if the flat blade screwdriver slips. Also, with an S4 Barco, your tool count is down to 2 drivers (unless you are working with the lens mount).

                Comment

                • Leo Enticknap
                  Film God
                  • Jan 2020
                  • 3576
                  • Loma Linda, CA

                  #23
                  I carry two containers of M3-.5 x 8 (Barco faceplate) screws in my tool kit, one of them with no. 2 Phillips heads, and the other with T10 heads. Whenever I encounter a Barco Series 2 projector, I replace any faceplate screws that aren't no. 2 Phillips head to ones that are, and for Series 4s, any that aren't T10 to ones that are. To reduce the risk of someone else damaging a head (or even worse, shearing it off) because they don't have the right driver, I like to standardize the faceplate screws to either the Series 2 convention (either 2.5mm or 3mm Allen, or no. 2 Phillips head) or the Series 4 convention (T10 or T20, with one or two rare exceptions).​

                  Comment

                  Working...