Forum
INCORRECT START SIGNAL
Quote from Antonio Amo on November 19, 2020, 2:05 amHello,
I have participated in your previous forum version, where you have been extremely helpful.
I have detected a problem using the code you helped me to create. It seems the software detects the START signal (machine working) as soon as the machine operator selects the MEM (auto) option, regardless of if the "green button" is pressed. I am not sure if this is a programming issue or machine configuration, but it causes the calculated data (OEE) to be higher than it really is.
Is there any way of correcting this? Thanks,
Regards.
Hello,
I have participated in your previous forum version, where you have been extremely helpful.
I have detected a problem using the code you helped me to create. It seems the software detects the START signal (machine working) as soon as the machine operator selects the MEM (auto) option, regardless of if the "green button" is pressed. I am not sure if this is a programming issue or machine configuration, but it causes the calculated data (OEE) to be higher than it really is.
Is there any way of correcting this? Thanks,
Regards.
Quote from Versex on November 19, 2020, 8:39 amHi Antonio,
Thank you for posting in here. I am hoping that this can be used as a place for people to come and learn more about Fanuc Focas.
As for the issue with the start signal (I assume you are referring to G0.7). Are you drip-feeding the programs? If you are, that is not a scenario I have really tested out before. Does the cycle counter on the CNC start when you press the MEM key also? That is something I will ask about next time I am in the office.
Hi Antonio,
Thank you for posting in here. I am hoping that this can be used as a place for people to come and learn more about Fanuc Focas.
As for the issue with the start signal (I assume you are referring to G0.7). Are you drip-feeding the programs? If you are, that is not a scenario I have really tested out before. Does the cycle counter on the CNC start when you press the MEM key also? That is something I will ask about next time I am in the office.
Quote from Antonio Amo on November 19, 2020, 1:55 pmHello,
Apologies, but I am not sure if I properly understood you (non native English speaker here). What do you mean by "drip-feeding the programs"?
We load the programs in the machine using an FTP (Filezilla or equivalent), and such program is loaded in the scenario I talked before. In the periodic cycle of signal-gathering we perform (currently each 120s, we plan to set it to 15-30s in the future), we ask several questions including current program, and the machine returns "program X" is this scenario, which is MEM key (that is, machine set to AUTO) is pressed, even if no green button (which signals the machine to physically start) is, alongsite with START as active (this is something we do not desire, that is, START signal only if machine is actively working).
By cycle counter, do you mean the part counter? (M30 signal, program ended). In this case, the answer will be no.
The START signal we are gathering is provided by the GetStatus() function you published in your previous forum style (It's Time to Focas Part 3). Maybe did I misundertood the meaning of that signal? The name in Heindenhain controls is the same (mode, status, etc) and here it works as expected.
Regards.
Hello,
Apologies, but I am not sure if I properly understood you (non native English speaker here). What do you mean by "drip-feeding the programs"?
We load the programs in the machine using an FTP (Filezilla or equivalent), and such program is loaded in the scenario I talked before. In the periodic cycle of signal-gathering we perform (currently each 120s, we plan to set it to 15-30s in the future), we ask several questions including current program, and the machine returns "program X" is this scenario, which is MEM key (that is, machine set to AUTO) is pressed, even if no green button (which signals the machine to physically start) is, alongsite with START as active (this is something we do not desire, that is, START signal only if machine is actively working).
By cycle counter, do you mean the part counter? (M30 signal, program ended). In this case, the answer will be no.
The START signal we are gathering is provided by the GetStatus() function you published in your previous forum style (It's Time to Focas Part 3). Maybe did I misundertood the meaning of that signal? The name in Heindenhain controls is the same (mode, status, etc) and here it works as expected.
Regards.
Quote from Versex on November 19, 2020, 8:01 pmHey Antonio,
So yes, I think you may have misunderstood what that does. All that is doing is telling you which mode the machine is currently set to. In order to see if a program is running (The program cycle time is counting) you can use the following code. Essentially, what this code does is check the G0.7 address. This bit will go high when a program has been started and when the program finishes (M30 or M02) the bit will go low. Let me know if this helps you!
if (Fanuc.Handle == 0)
return false;Focas1.IODBPMC0 m = new Focas1.IODBPMC0();
// Get address G0
_ret = Focas1.pmc_rdpmcrng(Fanuc.Handle, 1, 0, (ushort)(0, (ushort)0, 16, m);if (_ret == Focas1.EW_OK)
{// Check to see if bit 7 is equal to 1. If it is, return true, else return false.
// GetBit is a function I made to convert an integer to individual bits.
return m.cdata[0].GetBit(7) == 1 ? true : false;
}
Hey Antonio,
So yes, I think you may have misunderstood what that does. All that is doing is telling you which mode the machine is currently set to. In order to see if a program is running (The program cycle time is counting) you can use the following code. Essentially, what this code does is check the G0.7 address. This bit will go high when a program has been started and when the program finishes (M30 or M02) the bit will go low. Let me know if this helps you!
if (Fanuc.Handle == 0)
return false;Focas1.IODBPMC0 m = new Focas1.IODBPMC0();
// Get address G0
_ret = Focas1.pmc_rdpmcrng(Fanuc.Handle, 1, 0, (ushort)(0, (ushort)0, 16, m);if (_ret == Focas1.EW_OK)
{// Check to see if bit 7 is equal to 1. If it is, return true, else return false.
// GetBit is a function I made to convert an integer to individual bits.
return m.cdata[0].GetBit(7) == 1 ? true : false;
}
Quote from Antonio Amo on November 20, 2020, 3:17 amHello,
Thank you for your response. I missed in your original forum that your GetMode and GetStatus functions are essentially the same.
I have modified your code a bit and it seems to work, but I have a small doubt. In my case the 7th bith does not seem the correct one but the 5th. I have observed several integer values for our machines:
- Mechainizing --> m.cdata[0] = 224 (1110 0000)
- Not mechanizing case 1 --> m.cdata[0] = 192 (1100 0000)
- Not mechanizing case 2 --> m.cdata[0] = 64 (0100 0000)
As you can see, the differentiating bit seems the 5th (starting from bit 0). Could you confirm me if this is correct, or maybe there is something else I am missing? This is the GetStatus() funcion that I have now (where for us status 1 = mechaninizing; status 0 = machine IDLE/other)
public static int GetStatus()
{
if (_handle == 0)
return -1;Focas1.IODBPMC0 m = new Focas1.IODBPMC0();
_ret = Focas1.pmc_rdpmcrng(_handle, 1, 0, (ushort)0, (ushort)0, 16, m);
if (_ret == Focas1.EW_OK)
{//BitArray serves as an analog to what would be your bit extractor function
BitArray b = new BitArray(new byte[] { m.cdata[0] });
int[] bits = b.Cast<bool>().Select(bit => bit ? 1 : 0).ToArray();return bits[5];
}
else
return -1;
}
Regards.
Hello,
Thank you for your response. I missed in your original forum that your GetMode and GetStatus functions are essentially the same.
I have modified your code a bit and it seems to work, but I have a small doubt. In my case the 7th bith does not seem the correct one but the 5th. I have observed several integer values for our machines:
- Mechainizing --> m.cdata[0] = 224 (1110 0000)
- Not mechanizing case 1 --> m.cdata[0] = 192 (1100 0000)
- Not mechanizing case 2 --> m.cdata[0] = 64 (0100 0000)
As you can see, the differentiating bit seems the 5th (starting from bit 0). Could you confirm me if this is correct, or maybe there is something else I am missing? This is the GetStatus() funcion that I have now (where for us status 1 = mechaninizing; status 0 = machine IDLE/other)
public static int GetStatus()
{
if (_handle == 0)
return -1;
Focas1.IODBPMC0 m = new Focas1.IODBPMC0();
_ret = Focas1.pmc_rdpmcrng(_handle, 1, 0, (ushort)0, (ushort)0, 16, m);
if (_ret == Focas1.EW_OK)
{
//BitArray serves as an analog to what would be your bit extractor function
BitArray b = new BitArray(new byte[] { m.cdata[0] });
int[] bits = b.Cast<bool>().Select(bit => bit ? 1 : 0).ToArray();
return bits[5];
}
else
return -1;
}
Regards.
Quote from Versex on November 20, 2020, 7:58 amHi Antonio,
It may very well be different depending on which controller you have. If you tell me which controller, I can try to cross reference it with what we have. I am curious though.... Does it make a difference if you stop the program vs hit the reset button? What about if you hit an M02 vs an M30?
Hi Antonio,
It may very well be different depending on which controller you have. If you tell me which controller, I can try to cross reference it with what we have. I am curious though.... Does it make a difference if you stop the program vs hit the reset button? What about if you hit an M02 vs an M30?
Quote from Antonio Amo on November 20, 2020, 3:02 pmHello,
We have several Matsuura MX-520 and MX-850, both with NC Control Matsuura G-Tech 31i (fanuc based).
About M02 and M30, I will make several test the next week and will let you know.
Regards.
Hello,
We have several Matsuura MX-520 and MX-850, both with NC Control Matsuura G-Tech 31i (fanuc based).
About M02 and M30, I will make several test the next week and will let you know.
Regards.