Line identification in error codes... and more!

    When given an error code by the controller (DX100, in this case) generally there's an output for the location where the error occurred. L:#### where # is the number or whatever.


    I've found this at times somewhat inaccurate or hard to locate, in some cases it absolutely nails it and in others it lands on what generally turns out to be an innocent line of code close to the problem, and in others like my current situation, it's baffling - the line its suggesting doesn't exist (it's a few dozen past the END statement.)


    So my question is - how does the program counter work? What does it count, what does it ignore, does it go into calls of subroutines/jobs and count those too? I'm relatively certain it starts at the NOP command, yes? I would assume at 0 or 1 and go from there. But this job is throwing an error at L:0641, my NOP statement is at 691... So via some absurdly complicated math I did, I deduced that the error should be at 1332... correct?


    My END statement, though - it is at 1271.


    As I said, I've had smaller versions of this problem before, but have always been able to locate the offending line. But after clearing multiple syntax errors and other quirks of our OLP's postprocessing routine - I'm getting a 3190[4] thrown at me, which according to the docus says It's an Error in Job Data Record - 'Record on the position data section is wrong for the format' ...wait, it's counting the lines that come before NOP now, isn't it - that literally just clicked as I was typing this. I wonder if this is true for all 3190 codes?


    I am still curious as to how the counting works, as other numbers have been off. Does it count commented lines, for instance?


    The line looks just like all the other coordinates, I'm not sure why it doesn't like this particular one, hmm...

  • Lemster68

    Approved the thread.
    Quote from WhyDoesMyRobotHateMe

    I've found this at times somewhat inaccurate or hard to locate, in some cases it absolutely nails it and in others it lands on what generally turns out to be an innocent line of code close to the problem, and in others like my current situation, it's baffling - the line its suggesting doesn't exist (it's a few dozen past the END statement.)


    So my question is - how does the program counter work? What does it count, what does it ignore, does it go into calls of subroutines/jobs and count those too? I'm relatively certain it starts at the NOP command, yes? I would assume at 0 or 1 and go from there. But this job is throwing an error at L:0641, my NOP statement is at 691... So via some absurdly complicated math I did, I deduced that the error should be at 1332... correct?


    My END statement, though - it is at 1271.

    The NOP is Line 0000. It may be some other number when you are looking at it in some other text editor, like you are. But to the controller the NOP at the top of a job is Line 0000.


    The error 3190[4] says It's an Error in Job Data Record - 'Record on the position data section is wrong for the format.' My experience with this error tends to be the number of positions in the header NPOS does not match the number of moves written in the job. When this error occurs the error will say L:******. The controller can't tell the line number because the problem is not between the NOP and END instructions, there is not a line number.

    I know a thing or two, because I’ve seen a thing or two. Don't even ask about a third thing. I won't know it.

    i think i found the issue. you are using P variables that are not declared in the header. also P1 is wrong, you must write P001.

    did you used a software to make yor code?

    That is one issue. The job appears to be corrupt. I spent about an hour trying to manipulate it by loading only moves and only portions of moves. The controller doesn't like it. I can get maybe 10 or 20 moves to load.


    What robot arm is this, a MA1900 or MA3010?

    I know a thing or two, because I’ve seen a thing or two. Don't even ask about a third thing. I won't know it.

    Quote from potis

    i think i found the issue. you are using P variables that are not declared in the header. also P1 is wrong, you must write P001.

    did you used a software to make yor code?

    Yes. I've been using an OLP suite to generate code and then tweaking it afterwards (Wasn't my choice of software, the guy before me picked it - but it appears to be extremely incompatible with the DX100).

    It was my understanding that P00x variables could be declared in the program with the SET command, sort of like your run-of-the-mill variable argument in any language. Is this incorrect? The P's without the three digit integer are how the SFTON/OF command references location is it not? Please, by all means educate me if I'm way off.


    Quote from 95devils

    That is one issue. The job appears to be corrupt. I spent about an hour trying to manipulate it by loading only moves and only portions of moves. The controller doesn't like it. I can get maybe 10 or 20 moves to load.


    What robot arm is this, a MA1900 or MA3010?

    MA3100 running off a DX100. It's a bit outdated, I know. But it is what we have to work with. Our external is the MH-1605.

    I just got back from Yaskawa's accelerated programming course and yeah, I mean I knew it wasn't posting proper code before but the format it posts is just... very wrong. We've got coordinated motion and touch sensing and COMARC and other such fun things enabled on the robot and I can program them with the pendant, but if I use the software the code it spits out looks... right-ish but not correct, as you've seen. Maybe a YRC or even a DX2 could run it but yeah.


    So you're saying the job is corrupt, as in the file itself? Or you're just referring to it being broken in general? I can get this program to create basic jobs, of like a few motions or linear welds, and they will post. But our parts are like, frames for mining equipment. The one I showed you is an example of how big our jobs are, and that doesn't even have any multi-pass, or touch up added yet. So for example, when I get the software to use touch sensing, or seam tracking (a must, the variance is significant always) or if I try to use coordinated motion so it will calculate the movement and relative movement of the positioner and torch respectively in real-time, it'll post code that the controller hates.



    Now - anyone reading this might be saying, "dude, just program with the pendant. That's the most reliable way to do it." and I'd agree, but there is a welder actively using the robot to produce parts - and he's there to stay. My job is to produce jobs for it while it's running. I'm currently considering a transition to MotoSim VRC on the advice of Yaskawa, but it just really doesn't sit well that I've wasted so much time getting this far with the other suite and now I've got to learn another one. I can program with a virtual pendant as if I were out there, which is perfectly functional but I know that a) replicating my cell from scratch is going to be a *bleep*ing *bleep* in the *bleeeeep* which is going to take time and b) manually creating relative jobs will not execute as smoothly as the other program was designed to calculate. Also c) the amount of money and time my company invested in the other really irks me.


    So if either of my most appreciated response-givers has any idea of how I should proceed, please - enlighten me. Or if anyone else has any mSim VRC experience or has a clue about the other stuff, by all means, respond and be showered in gratitude.

    p.s: I know I'm horribly long-winded I apologize

    I reached a point where there was no vacancy on the robot to write new programs by the end of 2017. Had my MotoSim training and hardware key in January 2018 and it was HUGE help. I now write almost everything in MotoSim. It has also let me experiment with different solutions to get the task at hand done in the most reliable way. By now we don't have a dedicated operator - the largest products take over 4h to complete, but the programs are writen so the robot wouldn't run into trouble - there is a "IF" for almost all possible scenarious. When the robot stops, it makes a call - it has a cellphone connected to it.

    MotoSim, if put into good use, can be a gamechanger.

    Quote from Reintz

    I reached a point where there was no vacancy on the robot to write new programs by the end of 2017. Had my MotoSim training and hardware key in January 2018 and it was HUGE help. I now write almost everything in MotoSim. It has also let me experiment with different solutions to get the task at hand done in the most reliable way. By now we don't have a dedicated operator - the largest products take over 4h to complete, but the programs are writen so the robot wouldn't run into trouble - there is a "IF" for almost all possible scenarious. When the robot stops, it makes a call - it has a cellphone connected to it.

    MotoSim, if put into good use, can be a gamechanger.

    We got MotoSim actually, after I went to Yaskawa for their accelerated programming course! Currently I'm using it to error-check my code but I haven't found the time yet to learn how to properly set up our cell. It seems pretty great, but the camera controls are a little wonky.

    You did not say which sim the other one is. A lot of them have post-processors which are supposed to spit out the proper code for your robot. It could be the case that you need to modify the post-processor, (if there is one with your other sim program), to get the correct code output. Yeah, I am a bit late on this conversation.

    Quote from Lemster68

    You did not say which sim the other one is. A lot of them have post-processors which are supposed to spit out the proper code for your robot. It could be the case that you need to modify the post-processor, (if there is one with your other sim program), to get the correct code output. Yeah, I am a bit late on this conversation.

    Yeah, that's by design - I don't want to turn people off of using their software just because of the issues I'm having. Rather not step on any toes.

Advertising from our partners