wfsteele

I wanted to synchronously trigger a gather at a particular point in a motion program by using a synchronous assignment: Gather.Enable == 2 but it didn't work. According to the documentation for synchronous assignments, local variables and self-assigned M-variables cannot be assigned to this way, the implication being that anything else is OK. Since Gather.Enable isn't included in either of those categories, I assumed it would work. If, instead I synchronously assign a Q-variable, and then, in a plc program, enable gather when the Q-variable changes; that works (but then there's the latency of the plc program), so I know that the synchronous assign mechanism is working.

Upon installing a pre-release version of the firmware (1.5.6.0), once again the PPMAC came up with sys.noclocks = 1 and I had to manually set cid[4].dir = 1 to use the ACC-5E clock.

Both pennells & I had the same problem, so I think that it is a real problem. One thing that pennells & I have in common is that the ACC-5E card has the optional second Gate2 chip. Perhaps Delta-Tau used the single chip version in their attempt to duplicate the problem, which, possibly, only appears with the dual chip version.

Each UMAC card using Gate2 chip(s) (such as the ACC-5E) has a bi-directional buffer chip interfacing the board's clock to the bus. The direction of the clock has to be set for each buffer chip (this is in addition to setting PhaseServoDir on the Gate2 chip(s)). This only applies to board using Gate2 chips, boards with Gate3 chips do this automatically when setting the PhaseClock direction. When the ACC5E is sourcing the PhaseClock, the buffer chip direction must be set by assigning the value 1 to Cid[n].Dir, where n depends on the Gate2 chip number. For Gate2[0] set Cid[4].Dir = 1. Check the table on page 1014 of the Power PMAC software manual. Also read pages 36 - 37 in the Power PMAC User's manual. I encountered the same problem after upgrading to the new firmware last month. Apparently the older firmware took care of all this upon $$$***, but the new firmware seems not too. I submitted a complaint about this a month ago, which seems to have been ignored.

I frequently see this problem as well. Using Windows 7 with the latest (Sept 11) IDE. This happens in the position window, as well as velocity, watch, and sometimes motor status. It is quite annoying, the only way I can fix it is close the window and reopen it.

That is indeed the problem. SyncOps for CS 1 & 2 is zero. I checked for a few others (0, 3, 4); they are 8192. CS 1 & 2 are the two that I am using. I didn't (knowingly) set SyncOps to zero; what might I have done to inadvertently do that? Anyway, I made the correction and now the PLC program works correctly; thanks for your help! I found that if I leave out the parenthesis: yy -.2; the ide shows many errors, but, as you suggest, the PPMAC executes the program correctly. I also discovered that if I omit the trailing semicolon, the errors go away. I am using ide version 1.4.0.62 and firmware version 1.4.0.27.

abs/inc is not the issue. I want it to be abs and, for now, I'm relying on that being the default. Anyway, as I said in the original post, if I comment out the synchronous assign, the program works exactly as I expect it to; I just have to manually (with an online command) set P4 to 1 after I notice that the move has completed. Also, as I said, once I have run the program (with the synchronous assign in force) I cannot do an axis move for any axis in CS 2 until I reset the PPMAC. I have 2 motors in the coordinate system, assigned to axes xx and yy. Motor #5 is assigned to xx and motor #6 is assigned to yy. After running the PLC program, if I try an online command like &2 cx xx 2 or &2 cx yy -5 nothing happens. (The particular target position I choose doesn't matter; I have tried many different ones). However I can successfully jog motors 5 & 6, e.g.: #5j^100000 works correctly. It appears, at least in my case, that adding an item to the the synchronous assign queue for CS 2 hangs up the mechanism for doing axis moves in that coordinate system. (Note: other coordinate systems still work OK; for example an online command like: &1 cx yy 150 works OK.) What you did in your test and what I am doing appear to be identical, but with different results. So we must actually be doing something differently, but I don't know what that might be. Regarding the numeric constant: You didn't comment on the parenthesis. If indeed they are required for a negative numeric constant, I believe the documentation should clearly state that. The case of the leading zero is strange. I found that it is possible to get it to work without the leading zero. If, in the editor, I remove the leading zero, I get a list of 11 errors (the editor also displays some squiggly underlines in the program listing to indicate were there are errors). Then, if I click somewhere else in the editor window, the errors go away. I hadn't noticed that before because I had been editing with an external editor. When the file is saved, the ide notices that and asks if it should update itself to use the newly saved file. I click yes and it displays the errors (in the case of no leading zero). So the conclusion is: there is some sort of flakey behavior going on; under some circumstances starting a numeric constant (in this context) with a decimal point will generate (many) errors.

I tried to use a synchronous assignment in a PLC program, but I couldn't get it to work. Here's what I tried: open plc 2 Ldata.Coord = 2; P4 = 0; //P4 == 1; yy (-0.2); while (!(Coord[2].DesVelZero && P4)){} disable plc 2 close What happens when I try to run this (with the sync assignment not commented out) is ... nothing, no errors, no motion. According to the Task Manager, the PLC runs for a hundred usec or so and then stops, but nothing happens. In fact, after running this, I can never again move any axis in CS 2 (with an axis move command, motor jog commands still work) until I reset ($$$) the PPMAC. (Axis move commands in other CSs do still work). If I run this with the sync assignment commented out as shown, then the yy axis moves as commanded and the PLC remains running until I enter the online command P4 = 1, at which time the while loop exits and the PLC terminates. Aside: I initially tried the move command: yy -.2; it didn't work and there was no error indication (with the older ide. After installing the just released ide and trying again, there was indication of an error). Although -.2 is a numeric constant which, according to the documentation, is not required to be enclosed in parenthesis, I suspected that the minus sign was causing a problem. So I tried: yy (-.2); That didn't work either. Again, with the Sept ide, there was an error indication (but not much of a clue as to the problem). Then I tried: yy (-0.2); That did work. It seems to me that all 3 of these should work, at least according to what the documentation says.

I use both ethernet interfaces (static IPs for each), each on different networks. I would like to setup resolv.conf for one of them, the other does not have access to a DNS server. If I specify a DNS server in resolv.conf, it causes problems for the ethernet interface that can't find it. Is it somehow possible to separately specify DNS servers for the two interfaces?

I have run across what appears to be a firmware bug involving coordinate system definition. I was able to recover by resetting the PPMAC, but it is somewhat worrisome that (seemingly innocuous) actions can result in failure. I am using 3 motors, #'s 4, 5, and 6. I set up 2 coordinate systems, 1 and 2. I put motor 4 into CS 1: &1#4->{scale factor}yy And then 5 and 6 into CS2: &2#5->{sf}xx &2#6->{sf}zz Then I tried moving the motors with axis commands: cx yy {value} cx xx {value} cx zz {value} moving the yy and xx axes worked fine, but when I tried moving zz, gpascii crashed with a segfault. Experimenting, trying to find something that worked, I eventually wound up changing the CS definition for &2, using axis yy instead of zz for motor #6. I was then able to move motors 5 and 6 with the axis commands for xx and yy. But things still were not right. The first anomaly that I noticed was that the reporting command: &2p would return axis positions for the xx and yy axis, as it should, but also returned a position (zero) for the zz axis, which no longer existed in the CS definition. But, still, things worked OK, ... for awhile. I'm not sure what might have happened to change things, but after awhile I noticed that the axis commands no longer worked; typing a command like: &2cx yy {value} would do nothing at all, no error, no motion, all status indicators (closed loop, phase found, homecomplete, etc.) OK. At this point, the command &2p returned the message: 'no data to report'. I checked the CS definitions in the IDE and it all looked correct. So I had no recourse other than to reset the PPMAC. After the reset, everything worked fine. I'm not sure if trying initially to use the zz coordinate was what got me into trouble, but the project I'm working on is on a tight schedule so I can't afford to spend much time trying to figure this out. But I thought I should at least report the incident.

How can I prevent C background programs from being executed after a build & download (or, for that matter, a reset or power up)? I know that running the background programs may be controlled by the run entry in the [LINUX_PROGRAMS] section of the pp_proj.ini file, but the IDE insists on constructing a new pp_proj.ini file each time it downloads, and it always sets the background programs to run. This newly constructed .ini file overwrites any modified file I may have on the PPMAC. I have been unable to find a way to tell the IDE to do otherwise.

How do I mount an SD card? I found this post from 2009, but it doesn't work. Neither /dev/sdb1 nor /media/sd exist.

MACRO is setup correctly; the online command macroslave0,i920 works as expected. You are correct, in a plc program cmd "macroslaveread0,i920,p1" works. However, I expected the macroslaveread command to work as a program command as it does in TurboPMAC. There is little or no reason to use this command as an online command; it is useful in a program to get the value into a register so that further calculations can be done in the program. Having to use the cmd"" syntax in a program makes things difficult because there is no clean way to synchronize the rest of the program with the updating of the destination register.

The reason I posted the question was that I tried that syntax and it didn't work. The online command: MacroSlave0,I920 works, but the program command: MacroSlaveRead0,I920,P1 does not. When I try to download that statement, I get the error: "invalid data".

What is the correct syntax for the MacroSlaveRead program command?