OPP Cards Displaying Status on Remote PC, 9/4/2014

So two weeks ago, a board was sent out to the board house (Iteadstudio) and all was well. I needed to get that work item done, so while it was being manufactured, and shipped I could do other things in parallel. I spent the next week trying to scare somebody away from the project, but utterly failed in that attempt. He has an old playfield Bullseye/301 with nothing to drive it. No cabinet, no electronics…basically a perfect match for using OPP cards. Joe has been dogging it lately (something about being busy with something other than designing his pinball machine), so I haven’t gotten as much feedback as I wanted from him.

I feel to insure the viability of an open source project, it needs to either be so simple that no documentation is needed, or there has to be enough information so that a person who understands the topic can easily find the necessary documentation. Pinball controllers are relatively complex. There are three main boards that are required to control a pinball machine. The overall design, architecture, and implementation are in my head, but how does a person that simply wants to re-use the board designs start with their machine?

The only way that I can make sure the information is available is to get somebody else to use the cards, and to document questions and steps during the process. Essentially take on an alpha customer to force the information to be generated. Joe was supposed to be that person, but alas, building a machine completely from scratch takes a long time. I’ve had the cards for more than two years (actually almost three) at this point, but things moved at a snails pace. (Much of it was caused by fear of actually cutting whitewood. If I had a CNC router, it would be a much easier process, but to build one of those, it is a couple month hit in time.) When the SS2 playfield was purchased, the decision was made to bring it back to life. It does not have a fan layout so that actually drew me to it. SS2 is relatively rare, which makes it more appealing to me. Next big step forward was getting a rotisserie. I had set up the Camelot playfield and batted the ball around, controlled all the solenoids, but it was sitting on blocks of wood, and with every flip of the flipper, it would almost fall off the table. Every time I wanted to work on the underside, it would be a half an hour production to go between the table top setup, and the leaning against the wall so I could solder it. A couple months ago I built the rotisserie, and it lets me move between playing and wiring in the span of about a minute. With the amount of testing that I did on the SS2 playfield and previous tests, I felt confident in the cards. When the new person contacted me about getting a few cards to drive his playfield, it seemed like a good match. He seems technical enough to get it working, and from reading his blog, it seems that he is better with a soldering iron than I will ever be. Once he gets some information up on his website I will post a link to it.

Last week I sent him enough cards to control the playfield and read all the switch inputs. After sending those, I immediately realized that he would need some sort of documentation to start the rewiring of the playfield. Well, all the information is in the blog, but who has the time to go through two years of my random mumblings (most of it pointless) to find the technical details. I’ve started a rewiring a playfield document to provide this information. The initial version of the document should be available in the repository by the time I post this blog entry. There is also another guy, (I think I’m calling him Pierre since he is from Canada), who says he wants to take care of the Google code repository wiki. That would be a perfect place to put much of this information or at least pointers of where to find it.

So last weekend after building cards, shipping cards, working on a document, etc., I finally got back to working on SS2. I finished the wiring for all the switch inputs, and wired the communications between all the cards. I dragged the laptop down to the basement, and ran PinBrdGui.py.

PinBrdGui is basically a debugging aid that I wrote a couple months ago. You tell it what serial port to look at, and it goes out and auto-discovers all the boards on that serial port. In SS2, there are two solenoid boards and two input boards. It displays the current state of each of the switch inputs on the input cards, and it displays if a solenoid has been triggered on solenoid cards. Input cards can also be configured to report edges, but that is not as useful to debug if the switches are working. When a solenoid bit detects the correct edge (usually falling edge since input bits are pulled up, and closing the switch grounds them), the next status read from the card will have a ‘1’ in the correct bit position indicating the solenoid has fired. After the status is read, the solenoid driver card clears the status bit automatically. That means if the main processor doesn’t get around to reading the status for a while, it will not miss the fact that a solenoid has fired. In the embedded world these types of bits are called clear on read bits.

So here is a link to the video of the laptop getting real time status of input bits, solenoid kicks, from all the SS2 cards. https://www.youtube.com/watch?v=jKv1SIMZt1w. Couple notes on the video. On solenoid card #1, you can see the lsb fluttering. That is caused by a manufacturing defect on the card (probably a whisker of solder). That should only take about 5 minutes to fix when I have the time. The PinBrdGui helped me figure out that issue immediately since I could leave the switch open and see the fluttering, and close the switch, and see the fluttering immediately stop. Some persistence should be added to the displaying of the solenoid status bits. Since the status rate is so fast and the bit is only set for a single frame, it is easy to miss a solenoid input bit going past. A frame rate should be added. I’ve estimated and calculated the worst case status frame rate, but having PinBrdGui print out the actual number of frames per second would be a great debugging tool.

I have notes to write about 10 more things, and frankly I need to finish the playfield rewiring document. In the above blog entry, I promised the document would be finished before I posted this. I lied. I’ll write more after that is in the first draft form.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s