From test board to prototype

[Marc Rechté]

Test board:

To prototype PCB:

[Marc Rechté]

Ready to be tested...

[Dan - aka BorgDog]

looking good (from my amateurs' eyes anyway).  let us know how it works out.

[cobra18t]

Very nice! On the next rev, I would add pull-down resistors to the gates of the FETs. Also, I see current limiting resistors on D17-D32 but not on D1-D16. Are there other components on the bottom side?

[Marc Rechté]

Thanks for the feedback. I would assume LED + resistor act as pull down.

[OPP]

Take this with a grain of salt, but doing a quick look at the data sheet, maximum source/sink current for the whole STM32F103x8 (Sigma IINJ is +/-25mA, Table 7, page 37).  https://www.st.com/resource/en/datasheet/stm32f103c8.pdf

Because of that, I would beef up the resistors on the source side.  Right now the maximum source current is around 64mA.  Change the 820 ohm resistors to higher values.  I would choose something like 3.3 Kohm resistors.  That would keep you well below the 25mA maximum source if you start driving all of your coils at once.  I'd also use the same 3.3K resistors on the inputs side because why use 2 values of resistors when just one will work.  Makes for easier populating of the board, less different parts, blah, blah, blah.

Sometimes people add a couple extra pins to connectors to have blocked pins to insure that the wrong cable can't be plugged into the wrong position.  I would separate my high voltage grounds (connected to the source of the NChan MOSFETs) from my processor/logic grounds.  If you want to connect them on the board, use either a jumper or solder bridge.  (Of course, then you will constantly be worried that people aren't correctly attaching their grounds together properly.)  Looks good!

-H

[Marc Rechté]

I checked the MCU datasheet table 7, what I can read is that total sink current should not exceed 150mA in total, 25mA per pin.
Regarding grounds, I wonder how it would be possible to drive FETs if their ground are not connected to MCU ground.

[OPP]

Re-reading the spec sheet (and all the notes this time) I believe you are right.  Maximum 150mA for sourced/sunk current with 25mA max for each I/O pin.  The other parameters are for injected current which occurs with inputs above VDD or below VSS.  My bad.  I'd still choose 1 resistor value to make population even easier.  It doesn't take much current to make an LED bright enough for debug purposes.

The point on the grounds is about separating the logic/processor grounds from the high voltage grounds.  The coils are probably driven from a high voltage power supply.  The processor and logic grounds are probably from a low voltage power supply.  The grounds from both of these power supplies need to be tied together somewhere.  It is best to do that near the power supplies but it can be on the board.  I'm guessing the blue pill is being powered from the USB port.  All of the grounds going to the switch inputs should be attached to a gnd pin that is from the blue pill.  Then those big ground spades should go to the high voltage supply ground.  It is tough to know how all the grounds are connected without seeing the gerbers.

Let's say a couple of coils are firing.  Each one is maybe 10ish amps to be conservative (48V with 4.7 ohms for a red williams coil).  That means 20 Amps is zooming through the board to the ground spades.  All that current needs to go back to the ground of the 48V power supply.  As it goes zooming across the board, the resistance of the trace causes the ground reference to be a higher voltage.   This could cause ground bounce on the board.  It probably won't matter, but by separating the grounds cleanly it can't happen.

If the board connects the gnd pin(s) from the blue pill to some pin that you can use to feed the switch closures, and then another gnd pin connects directly to big ground pin traces, everything will work perfectly.  If all the grounds are connected together, it will still probably work perfect, but it isn't ideal.

Sorry for such a pitiful long winded message, but I find it difficult to explain grounds and how they should be separated and connected clearly.

-H 

[Marc Rechté]

Sister card is ready: 32 outputs

I have not published the kicad files, as I found 2 problems that need to be fixed before. https://gitlab.com/mrechte/open-pinball-project

[Hugh R Spahr]

Nice job.  I believe that you should be able to drive the board without changes through MPF as an OPP board with four incandescent wing boards.  (I.e. that should allow on/off of these MOSFETs).  Here is the applicable MPF documentation where they are called lights.  https://missionpinball.org/hardware/opp/lights/.  Just note that this won't make use of the "real time" aspects of the firmware.  It doesn't support things like receiving an input bit and firing a coil for a certain number of ms.  The firmware could be extended to support this, but MPF would also need to send an external trigger to fire the coil.  That may be useful for driving something like a bingo machine or even a large EM style backbox where real time performance for scoring isn't required.  I don't know if this would work well for things like pops or slingshots because the input would first need to be read by the host (MPF) then a command would need to be sent to this board to trigger a coil cycle.  (Maybe it would be fast enough, but it would be very system/host computer speed dependent)  The counter argument to that is that I've seen MPF send multiple messages in a second, and if it can rcv/xmt commands in a low number of ms, it should work well.

Nice job on the board!

-H

--
You received this message because you are subscribed to a topic in the Google Groups "MPF Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mpf-users/fBTue_cSHhU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mpf-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mpf-users/f54008a3-d0c6-42b5-8f25-5ed47a9a4221n%40googlegroups.com.

[Marc Rechté]

Thanks for your support.

Yes I assume MFP won't have to be patched for this card. However for opp16o16i, it will require to introduce a new wing type (WING_SOL_8).

I just published the kicad files (revision 1).

Marc

[Hugh R Spahr]

Isn't an OPP 16o16i simply the 4 solenoid wing board configuration?  Keep all of the high current stuff on the one side of the PCB through routing of the MOSFETs to one side of a card.  The PCBs seem to be relatively large so the routing of the drive/input signals to a banks should be easy.

--

You received this message because you are subscribed to a topic in the Google Groups "MPF Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mpf-users/fBTue_cSHhU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mpf-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mpf-users/8a560bdc-e803-4bc4-9da5-e80eaab00ea5n%40googlegroups.com.

[Thomas Fulenwider]

I think he might have gone with two wings of inputs and two wings of outputs as opposed to conforming to the existing wing options. If you want to do a board spin, you can do 4 solenoid wings as OPP suggests and still get 16 in and 16 out.

To view this discussion on the web visit https://groups.google.com/d/msgid/mpf-users/CAD9bh00o91SB9nO07RjPauw9_c%2BVQGr4e6-EMb%2BtMWMRPVoDUw%40mail.gmail.com.

[Hugh R Spahr]

Just saying if you do it as 4 sol wings, there are no changes needed for MPF and no changes for firmware.  Since a PCB is being created, it is pretty simple to route the signals to the desired position on the PCB.

The 32 solenoids would need changes because there is only an array of 16 solenoid objects in the firmware if you want to control them as solenoids  (i.e. fire for a 32 ms pulse).  There is also the issue of the non-volatile configuration of the solenoid only has 16 configuration positions.  I don't really understand what the use case is, so it is tough to say exactly what changes would be necessary.

-H

To view this discussion on the web visit https://groups.google.com/d/msgid/mpf-users/CABMT2j3n%3DyT_uz1WP5vKvy7OPSOVVoWwo7f80-bCCkHJF4-9Yg%40mail.gmail.com.

[Marc Rechté]

WING_SOL makes the assumption that 4 lines are outputs and 4 lines inputs. In case where you have many solenoids that are software driven only, it is a waste of I/O lines.

In fact WING_SOL_8 is applicable to both opp32o and opp16o16i, providing you do not have more than 2 wings of this type.

It becomes possible to use opp32o to drive 16 lamps + 16 solenoids.

Firmware has been updated accordingly including flash config saving.

Another concern I have regarding MPF is the way cards are identified through their device name (/dev/tty...), and not their seial number, which would make configuration easier than writing obscure udev rules...

Télécharger TypeApp pour Android

[cobra18t]

MPF can identify the cards by their serial number. That is exactly what I do for CobraPin. You have to identify which ports you use, but it does not matter which port each of the cards grab. No special udev rules.

A snippet from: https://missionpinball.org/hardware/opp/cobrapin/

#config_version=5 #CobraPin Example Config hardware: platform: opp driverboards: gen2 opp: #Use the USB ports defined by your OS for the two STM32 boards ports: /dev/ttyACM0, /dev/ttyACM1 #USING SERIAL NUMBERS INSTEAD OF CHAINS # Board 0 has serial number 0, Board 1 has serial number 1. # This is convenient if your OS tends to reassign the serial port. # MPF will automatically address the correct board even if the ports # are swapped. #For multiple CobraPin boards in a game, you will either have to give # the STM32 boards on the second CobraPin board new serial numbers # (10 and 11 are suggested for the 2nd board since 2 is used by the # CobraPin Xpansion Board) # <OR> Use the chains section to assign a port to a board number. # Mixing these up could cause blown FETs, coils, and fuses. Proceed # with caution. Test without coil power and use the yellow coil LEDs # for feedback. #chains: #0: /dev/ttyACM0 #1: /dev/ttyACM1

[Marc Rechté]

+1. Thanks

Télécharger TypeApp pour Android