Frosty_4th
Member
- Join Date
- Jan 2005
- Posts
- 5
We've been asked by a client of ours to convert an old application we originally wrote in "C" for use on an embedded processor to now run on a Mitsubishi Melsec Q-Series PLC. The development environment will be GX Developer. We've written ladder logic before, but never on a Mitsubishi PLC and never using GX Developer. We've downloaded the trial version of GX, however the help files have not been very helpful. Below is a summary of our application:
1. Its purpose is to detect and profile objects that pass through a series of sensors. The sensors will appear as digital inputs to the PLC by using the Q-Series QX40-S1 input module. The sensors used to profile the object passing by are basically proximity sensors. A signal from a light curtain is used to indicate when the object has cleared the area where the proximity sensors are mounted which completes the profiling for that object.
2. In total there are digital 7 inputs. 6 are proximity sensors, and one is the light curtain.
3. Depending upon the order in which the proximity signals turn ON/OFF, decisions are made for certain attributes of the object being profiled. I.e., sensor A turning on before sensor B means one thing, whereas sensor B turning on before sensor A means something else.
4. Profile data is also calculated using the relative time each sensor is in its on or off state. Our "C" code currently accomplishes this by time stamping the transitions of each signal down to the millisecond and comparing the relative time of one sensor against another. We haven't found any references to GX supporting timestamps so implementing this part of our current "C" logic in GX is an unknown.
5. When the light curtain signal changes from ON to OFF, it means the object has cleared the area where the sensors are mounted. That causes our logic to send the profile results for the object that just passed by. Currently these results are sent using a serial protocol but will need to be ported to use shared memory within the PLC to “talk” to another CPU mounted on the same base unit. The design of our client's PLC setup will include 2 CPUs (both are model Q02). Our profiling logic will run on one CPU, and other existing logic related to the overall application will run on the other CPU. We will send the profile data gathered for the object to an area of shared memory. Our clients program running on the 2nd CPU will read our profile results and use it in the existing logic for their application.
Our questions are:
1) Can GX be used for the type of logic used by our application, especially given that we need timestamps (relative or absolute) for sensor transitions?
2) Approximately how long would it take to port the logic to a Q Series PLC using GX Developer? This is of course a loaded question as you don’t have access to the original code, but I believe we have outlined the areas in the code that may cause the most problem (i.e., time-stamping).
3) What kind of timeframe is the learning curve for GX Developer provided we take some training classes? Are we talking weeks, months, or years?
4) Are there any GX Developer users out there that are available on a contract basis to aid in the porting and to help get us over the learning curve?
5) Is there emulation software available for windows that would allow testing of the program as it is developed, or will the program need to be downloaded to a PLC and run?
Thanks in advance
John
1. Its purpose is to detect and profile objects that pass through a series of sensors. The sensors will appear as digital inputs to the PLC by using the Q-Series QX40-S1 input module. The sensors used to profile the object passing by are basically proximity sensors. A signal from a light curtain is used to indicate when the object has cleared the area where the proximity sensors are mounted which completes the profiling for that object.
2. In total there are digital 7 inputs. 6 are proximity sensors, and one is the light curtain.
3. Depending upon the order in which the proximity signals turn ON/OFF, decisions are made for certain attributes of the object being profiled. I.e., sensor A turning on before sensor B means one thing, whereas sensor B turning on before sensor A means something else.
4. Profile data is also calculated using the relative time each sensor is in its on or off state. Our "C" code currently accomplishes this by time stamping the transitions of each signal down to the millisecond and comparing the relative time of one sensor against another. We haven't found any references to GX supporting timestamps so implementing this part of our current "C" logic in GX is an unknown.
5. When the light curtain signal changes from ON to OFF, it means the object has cleared the area where the sensors are mounted. That causes our logic to send the profile results for the object that just passed by. Currently these results are sent using a serial protocol but will need to be ported to use shared memory within the PLC to “talk” to another CPU mounted on the same base unit. The design of our client's PLC setup will include 2 CPUs (both are model Q02). Our profiling logic will run on one CPU, and other existing logic related to the overall application will run on the other CPU. We will send the profile data gathered for the object to an area of shared memory. Our clients program running on the 2nd CPU will read our profile results and use it in the existing logic for their application.
Our questions are:
1) Can GX be used for the type of logic used by our application, especially given that we need timestamps (relative or absolute) for sensor transitions?
2) Approximately how long would it take to port the logic to a Q Series PLC using GX Developer? This is of course a loaded question as you don’t have access to the original code, but I believe we have outlined the areas in the code that may cause the most problem (i.e., time-stamping).
3) What kind of timeframe is the learning curve for GX Developer provided we take some training classes? Are we talking weeks, months, or years?
4) Are there any GX Developer users out there that are available on a contract basis to aid in the porting and to help get us over the learning curve?
5) Is there emulation software available for windows that would allow testing of the program as it is developed, or will the program need to be downloaded to a PLC and run?
Thanks in advance
John