185 replies to this topic

[abispac]

sorry if this bothers you, its great that you found the problem and its a good alternative, but as i mentioned before , if its not fully automatic, it aint cab friendly, hope you can find a way to make it work automatic.

 

Ps i just tested the version you sent me plus the new esqueser and lights work, payouts dont, the counter still stays at 0 and the config files deletes by itself whe trying to type something into it.

Edited by abispac, 31 March 2019 - 03:37 PM.

[majoris]

Have you downloaded last version of MFME from given link? You should update emulator. Try to do that.

http://www.desertisl.../file/116-mfme/

 

Version of emulator I've sent you is for previous version of Squeezer. Updated squeezer will not work.

Use all informations from my update post. Download latest MFME, download Squeezer, run it. Should work.

[compuw22d]

Dude, awesome work.  I finally have everything working (may need to slow down the hopper a bit to avoid double payouts, need some testing, pretty sure it's not your code, or if it is maybe I'll re-code it a bit to use interrupts).  I did have one question, is there a way to "remove" channels from the sending stream?  I feel like it's sending data for every single pin, reducing the response time (I only have about 10 lights).  I'm thinking if I could make it "skip" the unused pins the response time would likely be better as it loops through the outputs faster if that makes sense.  Either way, awesome work!

[majoris]

I will think about adding ON/OFF channel. I have it implemented on my big test program for reel movement - checkboxes, so I can decide when to send or turn off channel.

It is going to take some time, because I can do anything only on weekends, but we will see. It can be done.

 

Do you experience any noticeable latency on your lights?

What kind of hopper you are using? Just curious.

As for hopper, I have only one confirmed isse - it skips first coin after software first run. After first payout with missed coin it runs perfectly.

[compuw22d]

Haven't gotten back home yet to test this, but I whipped up some code that I think will handle the hopper sensor a bit quicker using interrupts.  I haven't tested it yet, but let me know what you think.  NOTE YOU'LL HAVE TO MAKE SURE FRUITSQUEEZER IS NOT USING PIN 21 IN THE APPLICATION (I have no code to check for conflict, so don't send commands to a "light" on pin 21.

 

NOTE: My hopper activates (and outputs) LOW (0V to run hopper, trigger falls to 0V when a coin passes).  You may need to adjust the code accordingly.

 

EDIT: I'm using an MK4 Universal Hopper (24v).  Regarding Latency I do see the lights don't quite "match" on screen when blinking (they also don't light 'simultaneously', one after the other, which is a bit expected based on baud rate).  Quick flashes may be skipped (flashes 4 times on screen 2 on board) I think.  I didn't test it for too long.

#define hopSens 21 //pin wejściowy z sensowa optycznego (dekrementacja licznika hoppera)
#define hopMot 55 //pin wyzwalający zasilania silnika hoppera

int hopStat = 0; //ilość pulsów i tym samym monet do wypłaty
int SensorStat = 0; //aktualny stan sensora - wysoki lub niski
int lastSensorStat = 0; //poprzedni stan sensora - wysoki lub niski

void setup() {
  Serial.begin(115200);
  Serial.setTimeout(10);
  pinMode(1, OUTPUT);
  pinMode(2, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
  pinMode(7, OUTPUT);
  pinMode(8, OUTPUT);
  pinMode(9, OUTPUT);
  pinMode(10, OUTPUT);
  pinMode(11, OUTPUT);
  pinMode(12, OUTPUT);
  pinMode(13, OUTPUT);
  pinMode(14, OUTPUT);
  pinMode(15, OUTPUT);
  pinMode(16, OUTPUT);
  pinMode(17, OUTPUT);
  pinMode(18, OUTPUT);
  pinMode(19, OUTPUT);
  pinMode(20, OUTPUT);
  //pinMode(21, OUTPUT);
  pinMode(22, OUTPUT);
  pinMode(23, OUTPUT);
  pinMode(24, OUTPUT);
  pinMode(25, OUTPUT);
  pinMode(26, OUTPUT);
  pinMode(27, OUTPUT);
  pinMode(28, OUTPUT);
  pinMode(29, OUTPUT);
  pinMode(30, OUTPUT);
  pinMode(31, OUTPUT);
  pinMode(32, OUTPUT);
  pinMode(33, OUTPUT);
  pinMode(34, OUTPUT);
  pinMode(35, OUTPUT);
  pinMode(36, OUTPUT);
  pinMode(37, OUTPUT);
  pinMode(38, OUTPUT);
  pinMode(39, OUTPUT);
  pinMode(40, OUTPUT);
  pinMode(41, OUTPUT);
  pinMode(42, OUTPUT);
  pinMode(43, OUTPUT);
  pinMode(44, OUTPUT);
  pinMode(45, OUTPUT);
  pinMode(46, OUTPUT);
  pinMode(47, OUTPUT);
  pinMode(48, OUTPUT);
  pinMode(49, OUTPUT);
  pinMode(50, OUTPUT);
  pinMode(51, OUTPUT);
  pinMode(52, OUTPUT);
  pinMode(53, OUTPUT);
  pinMode(21, INPUT);
  digitalWrite(21, HIGH);
  attachInterrupt(digitalPinToInterrupt(21), HopperSensor, FALLING); //Set this to Rising if you have a "positive" trigger rather than ground
  pinMode(55, OUTPUT);
  pinMode(56, OUTPUT);
  pinMode(57, OUTPUT);
  pinMode(58, OUTPUT);
  pinMode(59, OUTPUT);
  pinMode(60, OUTPUT);
  pinMode(61, OUTPUT);
  pinMode(62, OUTPUT);
  pinMode(63, OUTPUT);
  pinMode(64, OUTPUT);
  pinMode(65, OUTPUT);
  pinMode(66, OUTPUT);
  pinMode(67, OUTPUT);
  pinMode(68, OUTPUT);
  pinMode(69, OUTPUT);
}



void loop()
{
//  SensorStat = digitalRead(hopSens); //przypisanie stanu sensora do pinu podpiętego do sensora hoppera

  if (Serial.available() > 0) //ten cały blok kodu czyta sygnały z seriala x-LEDy, c-monety
  {
    int hopSig = Serial.read();
    if (hopSig == 'c')
    {
      hopStat++;
      digitalWrite(hopMot, 0);
    }
    int pin = Serial.parseInt();
    int value = Serial.parseInt();

    if (Serial.read() == 'x')
    {
      digitalWrite(pin, value);
    }

	int pinA = Serial.parseInt();
    int valueA = Serial.parseInt();
    if (Serial.read() == 'f')
    {
      analogWrite(pinA, valueA);
    }
  }
}

void HopperSensor() {
  hopStat--;
  if (hopStat > 0) //jeśli licznik monet będzie większy od 0, zaczynamy zabawę
  {
    digitalWrite(hopMot, 0); //włączamy silnik hoppera i tym samym całe jego zasilanie
  }
  else
  {
    digitalWrite(hopMot, 1);
  }
}

Edited by compuw22d, 01 April 2019 - 09:19 PM.

[compuw22d]

I'm also wondering if it might be worth experiment with higher and/or adjustable baud rates (in the application, obviously sketch adjusted to match) to see if we can't reduce some of the latency.  Some interesting reading:

 

https://arduino.stac...ax-serial-speed

 

https://www.insidega...g-datasheet.pdf

"CH340 supports common baud rates: 50, 75, 100, 110, 134.5, 150, 300, 600, 900, 1200, 1800, 2400, 3600, 4800, 9600, 14400, 19200, 28800, 33600, 38400, 56000, 57600, 76800, 115200, 128000, 153600, 230400, 460800, 921600, 1500000, 2000000 baud. Transmitter baud rate error is less than 0.3%, receiver baud rate error tolerance is at most 2%."

[majoris]

I would have to dig out my electronic stuff and connect it back to life. Maybe I'll do that. From my experience I can tell, that I had no latency on my setup. I don't quite remember if I tested latency on Arduino Mega or UNO. I remember that I tested it on slo-mo video, and it has shown, that computer monitor was little behind the Arduino. I'll try to find this video.

Minimal latency is crucial for this project. I will check this out when I will have a moment. From your info I can see that we have a problem with latency on your setup. There is no way to loose some light flashes. I must check it.

 

As for interrupt on PIN 21. Well I was thinking on interrupts, and even tried one, but after some experiments I decided to write a code which compares coin sensor state. I got some errors on payout from my hopper using interrupt. I already forgotten some of the details of my thinking, so I can't tell you exactly why I did this. But I also used interrupt and resigned for some reason. Would be helpful to remember but I can't. Maybe I did something wrong with the code? Maybe I'll try your code to see how it runs. My code and "falling" interrupt looks to have same logic, so interrupt implementations seem to be a goog idea. Worth testing.

 

As for the baud rates, I don't see a problem. We can try higher values. 115 200 is le lowest usable rate for this solution. I've tried lower, but it fails. I don't think that higher baud rate would be any problem. First version of Squeezer had possibility to manualy set the baud rate, but I resigned. It is now hard coded to program. But we can change that.

[majoris]

I was too late to edit my post, so I have to put it here.

 

I have looked at my last video with example payout on Dam Buster game, and I confirm latency.

Some improvements on the software should be done to improve performance. Mostly the serial data flow. Higher baud rate and turning off unnecessary outputs.

Example video (put it to slow motion):

[compuw22d]

I also did a bit of testing with your hopper code (the time I thought I saw an extra coin drop was on a quick run home during my lunch break, so I didn't analyze it much).  Trying with PUTTY on the COM port and just hitting the c Key does appear to drop only 1 coin, so it seems the use of interrupts is likely unnecessary (I'm still using your code, not mine).  Still might be worth doing, but thought I'd post my findings in case it helps someone else.

[majoris]

I've done a quick refresh speed test and baud rate doesn't seem to have any impact for latency of lights. I'd say that Arduino reacts slight faster than computer monitor. Below I'm publishing two slow motion videos of START button lamp. Machine is running in attract mode to get most of the light signal commands running on the serial transmission.

 

115200 baud rate:

 

256000 baud rate:

[compuw22d]

I see what you mean, almost too fast    I am noticing some issues in getting a reliable connection to the Mega especially trying to run on startup.  Says connected but isn't, some random disconnecting, reconnecting, and re-opening the application seems to help.

[majoris]

Responsiveness of Fruit Squeezer - how should it run:

 

Some description in the video info.

At the beginnign while no MFME rom is loaded, Fruit Squeezer is scanning the memory for exact pattern (terrible lag), which is not found. Operation is repeated (still lags) untill we run the game. After game is started, program finds needed spot and stops scanning. We see zero lag. 100% responsiveness. After finding the game everything should run as on my example. If it doesn't then we have some problem. Fruit Squeezer will not work properly.

If it is running properly, everything should be automatic. Rom name finding, making config file, loading config values, connecting to COM port (only if saved to config), etc... All necessary cabinet features.

Edited by majoris, 02 April 2019 - 04:42 PM.

[compuw22d]

Yup, I'm poking around a bit.  Part of it was using task scheduler and I think had something to do with it not being "started" in the folder it was in?  The other part has something to do with the com text box.  A sure fire way to fix it with com ports is to hit refresh, click the com port in the list, then click the dropdown in top left corner, then BACKSPACE a bit in the text box of the COM port, then select it from the dropdown.  Debugging a bit more now...

[compuw22d]

I resolved the automatic connecting issue.  Installing Arduino and the official serial drivers seems to have helped quite a bit (though the built-in are usually decent...).

[abispac]

sorry to resurect this one, but i was wondering. i just build a cab with real igrosoft hardware, but would love to use mame as those boards brake real easy, so anyway, i wonder if Majoris or anyone ealse, can help figure out a way to make arduino work for the hopper, using mamehooker i can comunicate with the hopper and starts the hopper, for every coin mamehooker send a pulse, but the problem is the arduino does not have a code has MFME on wich when you send keystrokes for each coin, the arduino would tunr the hopper off. Anyway there was Eric too who claim he had it working , but cant seem to get a hold of him, hope someone ealse can help on this. Thanks for any help. If mods feel like this dont belong here or a should open this on a new topic, please let me know.

[majoris]

Just a quick update for MFME 19. Not fully tested, but working. Please report any issues. It took some time to publish this version. It was ready a long time ago, but had no time to finish.... time time time....

 

Dimming is working but I had to remove color changes from the Squeezer. It was crashing sometimes because of faulty memory reading on machine change. Now it is stable, but less spectacular. Anyway, It will work fine on Arduino.

Attached Files

•  Fruit Squeezer v. 0.88 (MFME 19).rar   131.3KB   21 downloads

[eric]

Hi Konrad,

 

Happy to have sommes news of your project.

Beautiful winter day, wtih mfme 19 and fruit squezzer in perspective...

have a nice day

Eric

[gareth_iowc]

do we need a special version of Fruit Squeezer to  used the screen output?

[majoris]

Yes mate. This is broader version. I have not published this one. It scans more spots in MFME memory process, and sends to COM port. For now the whole program is outdated, because of some memory addressing changes made by Wizard in MFME during the updates. To be honest I have no time to update the software, and to be even more honest I have lack of motivation .

 

The version presented on the video has more code, it can use two Arduinos to controll stuff. I had an ambition to program this thing to move stepper motors using CNC shield just like in real machine (shown on one of my videos), but I failed (but I know it can be done). Arduino forum did not help. No one helped. So whole project is suspended. If I will find someone (programmer) to cooperate with, to program the Arduino for stepper motors, then maybe whole idea would get alive again.

For now it is like it is.

Not much interrest on my idea. 7 downloads of latest version is not worth of my time no more. At the beginning I had more enthusiasm because I thought the idea had potential. It is verified now.

Stay healthy and take care of your family!

[gareth_iowc]

Ah man that really sucks, i think it's an amazing project.

 

I've also found the arduino forum to be a difficult please for help depending on your project.

 

Would you ever make it open source?