Jump to content
OMRON Forums

dorcsssc

Members
  • Posts

    16
  • Joined

  • Last visited

dorcsssc's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. I have a follow-up question about dual feedback concerning the programming (after a correct hook-up has been made). Clearly, in the PPMAC script language, motor[x].ActPos and .ActPos2 return the two encoder positions. However, at least for .ActPos, the actual value returned doesn't correspond directly to any motor structure value: experienced PPMAC C programmers have already found out the hard way that script language motor[x].ActPos corresponds to C language (M->ActPos - M->HomePos); that is, in the scripting language, the value relative to the captured home position encoder count is returned. So here's the question: Where's .HomePos2 (or conceptual equivalent)? Should I calculate an interpolated value for it based on the ratio of the two encoder scales? If so, what should I do prior to the axis being homed?
  2. Did I miss something near the end of the User's Guide about this? Or did I misunderstand an IDE menu item along these lines? Now that we're basically satisfied with the functioning of our background C application, we want to burn it into our PPMAC so that it will run whenever powered up, without the IDE. Please tell us how our production operators can run a PPMAC with this application without obliging them also to use the IDE. Thanks.
  3. Wait - - interval looks wrong due simply to using "%ul" instead of "%lu" in the format statement. So the lower-case 'l' suffix looks like an extra '1' digit, suggestings a number an order of magnitude larger. Oops. Our system fixed fonts are also partly to blame. OK, so that accounts for the interval. Good. Now what about the offset value, though. Why a "realtime" value of only ~22,000?
  4. I've just proven that the .tv_sec field of a increments by *10* every second on a PPMAC. Here's the code: struct timespec itval; itval.tv_sec = 42; // Just to verify value is being loaded. while (1) { if (clock_gettime(CLOCK_REALTIME, &itval) < 0) fprintf(stderr, "clock_gettime() barfed, code %d.\n", errno); else fprintf(stderr, "itval.tv_sec = %ul.\n", itval.tv_sec); sleep(1); } Both the range of the number (only a few hundred thousand - no even close to the 1970 epoch) and interval (10) are wrong? What's going on here? Has Xenomai monkeyd around with clock_gettime()?
  5. I've just proven that the .tv_sec field of a increments by *10* every second on a PPMAC. Here's the code: struct timespec itval; itval.tv_sec = 42; // Just to verify value is being loaded. while (1) { if (clock_gettime(CLOCK_REALTIME, &itval) < 0) fprintf(stderr, "clock_gettime() barfed, code %d.\n", errno); else fprintf(stderr, "itval.tv_sec = %ul.\n", itval.tv_sec); sleep(1); } Both the range of the number (only a few hundred thousand - no even close to the 1970 epoch) and interval (10) are wrong? What's going on here? Has Xenomai monkeyd around with clock_gettime()?
  6. dorcsssc

    C Debugger

    Minor update: just verified that it's the PC hosting the IDE that needs re-starting to clear the un-startable *.out program. Existing the IDE and re-starting it is not sufficient! This suggests a registry programming bug, since a toally clean build on an otherwise totally idle PPMAC really should result in a debuggable background C program.
  7. Sure looks like a gaffe to me: after just having set a new IP address, why does it insist on attempting to communicate with the PMAC using the OLD one? Isn't this why everyone is changing it in the first place? Also along the same lines, I allege that the whole notion of being required to "Test" the connect before setting it permanently is just not realistic; at the very least it needs an override. In this case we are quite certain what the IP address is (we're pinging it and telnet-ing into it just fine) - - but once again, the stupid thing insists on doing the test with the OLD IP address. Why is there not any means to just accept what I tell it and go with it? I can't even toggle the switch to "select device at startup" switch without it insisting on checking the com-link again. There's just way too much playing-God here, and not enough simple old-fashion DO-WHAT-I-TELL-YOU. Once again I have a perfectly-function PPMAC that I just can't communicate w/ using the IDE. The customer support meter will run once again. (*sigh*)
  8. Also bear in mind that the PPMAC IDE requires a specific prompt string ($PS1) format *and* being at a specific directory (/opt/ppmac) at the conclusion of root's login script. Tampering with either of those and the IDE won't be able to connect, and will opine that you have the wrong password.
  9. The question for this thread is why the PMAC IDE doesn't have its own account and set up the prompt the way it needs. Or conversely, why don't the users who want to customize the prompt set up special user accounts to do so? Good point. We did, in fact, add user accounts for 'developer' and 'operator'; we just didn't know that the IDE used the root account. In that regard, we concurr with your suggestion that the IDE should have its own account. In fact, we note there's already an account there called 'deltatau'.
  10. dorcsssc

    C Debugger

    Apparantly power-cycling the PPMAC *and* our workstation made the un-runnable program problem disappear, though I'm still not sure which one of these was the necessary one.
  11. dorcsssc

    C Debugger

    Oh, I forgot to mention one caveat: on the initial "Hello, PMAC" program, everything worked fine as far as the IDE and the debugging process, but we never found the output from the printf(). Anybody have ideas where it went? (That's *WHY* we next opted to fprintf() to a file at a known location, BTW).
  12. Here's one suggestion I made to my own development team in a report "closing" this issue: If we're ever in a position to make a recommendation to Delta Tau, I feel that both a more resilient and even surer means of distinguishing a valid & functioning PPMAC is for the login script (~/.profile) to define a special shell function that echos a specific identifying string. The IDE, after connecting, rather than examining the prompt, would invoke the special shell function (of a very uncommon name), and then would validate against the expected response. A simple - if somewhat cynical - example follows: challenge_RU_a_PPMAC() #Put this into /root/.pofile { echo "I solemny swear that I am indeed, a wholly-legitimate and properly-functioning PPMAC." } The IDE could then test for this string, rather expect a specific prompt AND a specific pre-positioning to a dedicated directory away from the login home. It could also incorporate $IPPROMPT, etc, if deemed necessary. This is even surer from a security standpoint because it functions as a bi-directional password: the challenge phrase (in this case, the function name) must also match as well as the expected reply.
  13. dorcsssc

    C Debugger

    Like JohnR and eboman11, I am experiencing the same thing with the current version. A simple "Hello, PPMAC" test program worked fine, including debugging it (setting breakpoints, single-stepping it, etc.). Then all I did was change the printf() to an fprintf() to a local file ("/tmp/stderr"), and now suddenly it is "Unable to start program ..."?
  14. OK, just so everybody knows, my issue was that both the format of the root prompt (which includes '\w' - reporting the current working directory), AND THE INITIAL DIRECTORY ITSELF - /opt/ppmac - have to be exact for the "format" of the prompt string to be considered a match by the IDE. The hard-coded change to /opt/ppmac really stood out as an oddity when I studied the login scripts (especially since it wasn't done via chaning the $HOME environment variable, but simply via a 'cd' to a hard-coded directory other than home) - - so I "fixed" it. Then I altered the prompt string to display the "journalism" items (who, what, where, when; er... in this case, root@IP_address//$PWD ), put each field in a different color... and before you know it - - the IDE would have nothing to do with it. I guess this all goes back to somebody telling me, "and it's also a general-purpose R/T linux system", instead of, "it's a turnkey system based on a R/T linux system - DO NOT MESS WITH IT".
  15. YIKES! How did this one get past the scrum? So, the good folks at Delta Tau are going to change that reject message to "Did you change the password or root prompt?", right? And they're going to warn about this in the user's guide, right? Because basically EVERYBODY wants to either put color in their prompt, or at least make SOME sort of customization to $PS1. Maybe the warning can more discreetly placed in the shell script where $IPPROMPT is defined (i.e., that it's required for the root prompt, and BTW, don't you dare mess with the root prompt, or else the IDE will reject it).
×
×
  • Create New...