Sign in to follow this  
Followers 0
JimRowell

Single Stepping

9 posts in this topic

Being a die-hard Medoc user, I have only a passing familiarity with GX. I see that it offers various debug options that don't exist in Medoc. Can anyone explain to me what the limits are with the FX series. I see more or less how the trace functions work. It looks to me that I can set up various locations to be recorded but I can NOT specify a STEP # when in FX mode. In other words, I can request the value of a location at the end of a scan but not at a particular step # (ie. BEFORE the value gets changed in a subsequent step). Is this correct? It also appears that I can not single step. Correct again? Thanks for your help. Jim Rowell

Share this post


Link to post
Share on other sites
Hmmm.... No takers, eh? Is that because nobody feels like typing or is it because nobody uses the debugging features? I was originally going to follow up by asking if anyone would be interested in a bit of commercial software that made debugging easier including single stepping on an FX and maybe graphing of values, table entry, etc. But I'm starting to think that I'm the only one that finds the current software limited. I can't be the only one writing difficult programs. You're getting me worried that I'm just really slow and make more errors than average. Jim Rowell

Share this post


Link to post
Share on other sites
Hi Jim, I missed the previous posts but here is one reply Actually before I can reply I would need some more infomration: I never used MEDOC and I'm not quite sure what was ment by 'step' in last posts (instruction step or sequencer/logic step?). What is FX mode? What do you consider difficult program (size, complexity of problem, number of I/O...)? Just wondering... Btw. I have my way of writting/debugging programs which I find very efficient and easy maintenable. I am always looking for interesting piece of code and I don't mind sharing knoweledge. Edited by panic mode

Share this post


Link to post
Share on other sites
"Single Step" means to make the processor (PLC in this case) step through your code, 1 line at a time. It gives you the oportunity to view variables as they change, see what branches are taken, that sort of thing. There are variations on this that are offered by most modern programing editors. Things like run for x number of lines or run to a certain point or stop when a certain condition is met. Then there is "tracing"which is recording the last several moves that were made by a program including certain values you may wish to watch. Medoc offers none of this for the FX series. Zero. Nada. GX offers some limited tracing from what I can gather but not being very familiar with GX, I was hoping for someone to describe exactly what it will and will not do. I frequently will insert code that will catch values for me and/or skip parts of a program when I'm trying to debug and test. But this is very time consuming and often not very effective. Thoughts? Jim

Share this post


Link to post
Share on other sites
Sorry Panic Mode, I should have addressed your points a little more specifically. In general use, when referring to debugging, "Stepping" means to not run continuously but rather in "steps". The definition of a step's size is usually configurable in many different ways. On the other, Plc manufacturures have traditionally used the term "step" to mean a program memory location (nothing to do with debugging - I guess they just love to confuse the issue) and that's what I meant when I asked if I could specify a Step # when defining where the program should stop. In other words, can I tell it to "step" to a particular "step #". Boy is that confusing! As far as what I mean by complex programming... Hard to say. My programs are generally not that big by some standards. 2,000 to 4,000 "steps" in size usually. They tend to be following high speed events, do complex math, have lots of boolean, several modes of operation, tons of error trapping for users, recipes, etc. Often I will have to connect with both a display and a PC. I find the debugging process to be a major part of the process and I'm not very happy with the tools at my disposal. I also do a lot of programming in Delphi on the PC and its overrun with debugging tools (both built-in and 3rd party). For the plc, I have only what I build for myself. What do you use for debugging your programs? Jim

Share this post


Link to post
Share on other sites
Honestly I never missed lack of such functionality like single stepping. I'ts not hard to make your own stepping if you really want it. For example: M0 - Goto Next Step M1 - NextStep Trigger M2 - Step Mode M100-M356 - Steps D10 - step counter Then just put M101 in front of first rung, M102 in front of second rung etc. Here is the code LD M0 PLS M1 LD M1 AND M2 INC D10 LD M2 DECO D10 K4M100 K16 LDI M2 FMOV hFFFF k4M100 K16

Share this post


Link to post
Share on other sites
Thanks for the reply Panic Mode, Well... a couple of thoughts... Your coding is good. But do you really want to put something in front of each line just to debug??? What if you have several thousand lines? For one thing, the speed would slow down to a crawl. Never mind the time to type it all in. I have my own similar way of doing it at present (I use jumps) but, like your's, it means modifying the program in a tedious and time-consuming fashion. Now the real question... You are obviously not a beginner. I assume you are writing large, complex programs. How can you say you've never had a reason to want better debugging tools? This is absolutely standard in every programming environment except plcs. Not just as a useless feature; it's used constantly by those programmers! So you've never have those problems where the program is not working the way you expected? And no matter how many times you read the code, you swear it should be okay? And then you waste untold amounts of time devising tests, pseudo-stepping modifications, value trapping etc., transfering to the plc, re-run the tests, etc? Never been there? What size of program do you typically write? Jim Rowell (aghast)

Share this post


Link to post
Share on other sites
Hi, ok let's see ... Program: Most of my Mitsubishi programs are also ca 4-6k steps and include working program with different modes of operation, recipes, communication, diagnostics and fault handling. Communication part can be quite complicated depending on how many devices you need to talk, who you deal with (some customer have strange rules), what they really want to accomplish and of course if you have any knoweledge/drivers for it or you have to develop something on your own. It happened to me already that I had to interface to something that nobody at customers place knew about (all you can see is cable with some funny looking round connector that doesn't exist in any catalogs I know of). If you ask me, reverse engineering sucks Some of the PLC programs I get to work on are much bigger (usually written by others so customers call me when they need support). Last such beast was ca. 14000 steps. I was able to not just fix it but also shrink it down to 25% of previous size in only few days (with *very* little sleep though...). I do lots of servo motion and communication. Debugging: I agree that this is extremly important aspect of programming. However, program should be broken down into smaller and more managable parts. Once one part is written and tested, I don't need to check it again. If I encounter new instruction or want to test some complicated calculation, then I use example posted before to step through couple of rungs till I get what I want. Once this works well I put nice big comment explaining what it does and suggest not to mess with it. This is also where portability of code comes to place (develop once then copy and paste where possible). There is no need to reinvent the wheel every time you repeat some project. When I work on other people code, I try to get the big picture. Once I know what is supposed to happen and not working part is found I either try to fix it or just rip it out and write my own code. I do my best to use simpe logic where ever possible, I'm trying to avoid complex instructions or logic where possible so that costomer (usually maintenance) can easily deal with it. Error Handling/Diagnostic: We do our best to make sure there is no 'issues' with equipment (or at least as little as possible). This is not easy to achive specially on complex projects where machine doesn't run by itself (you have operator(s)). In case machine is down built in diagnostic is supposed to be #1 troubleshooting tool. Well on occasion someone else might need to look into code to make modifications, see what program does etc. This is where #2 comes in place (comments comments comments). If #1 and #2 don't help, it's time for #3 (guys like me). Gee, it even rimes... Over time I just learned to use what is available. I certainly agree that GX developer could and should be much better . Things that kill me: - Keyboard (scrolling using arrow keys is waaaay too slow for my taste, cannot customize own shortkeys other than select one of three existing layouts. I hate vertical scrolling that steps through ladder comments, assigned shortcuts don't work or don't always work like anything+F3 etc. Pasting logic is a pain to line up unless you copy whole rung and many more...). - Fixed device organisation (I want to have 10, 20 or more D-files, M-files, B-files etc. to separate recipe, settings, communication etc.). - Data entry/data monitoring capabilities (dear Mitsi programmers, don't you think it would be nice to see device comments in "device batch"? also how do I *quickly* change 20 integers in a row for my message "Hello World"? I really like data tables in AB PLCs, point and edit! Ever tried to type "Hello World" in AB PLCs data tables?) - Going online/offline (Now, this is just terrible... It simply doesn't work... You can go online using program that doesn't match what is in PLC. To be online in edit mode, you HAVE to click on evey freaking file one by one... To go temporarily offline because laptop has only one com port and you want to fix something on screen for example, you have to close each and every window. Yess I know of Ctrl+F3 and Ctrl+Alt+F3, but this is not what I want and they also don't work all the time. When you open file (!) and want to check connection settings or IP address, "Transfer setup" is often grayed out. GX developer itself has no clue if it is online or not. Well at least they managed to bring out GOT developer that finally can use COM ports other than COM1-4 so the USB<>Com adapter saves my time ). - Make it ONE file PLEASE!!!!! (I've lost count how many times customer was emailing me with incomplete project or all files were compressed without folder structure so you have to manually recreate it) There is more to it, but if they could finally fix this, I would be much much happier to use their software. One thing I like a lot is rising and falling edge contacts (that's what AB is missing...) Edited by panic mode

Share this post


Link to post
Share on other sites
That's more like it, Panic. hehe For a minute there, you had me thinking that everything was wonderful and rosy in plc land. ;) I'm glad to hear you're not completely thrilled with the available software. I pretty much agree with everything you said. I think you would be amazed at how helpful the kind of debugging I'm talking about can be. You are very organized and careful by the sound of it and have a good aproach. But obviously, life still bites when it wants to. So if I can find another few thousand guys like you maybe I'll actually finish writing my Mitsi assembler/monitor.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0