Alex Anikstein

If they can be started at the same time and end at the same time, it would be easiest to just set both up as a single data gather and pretend you're only gathering "one" thing. Alternately, add all items to the list of items to gather, then start it when either set wants to be gathered and stop it when both sets are done. If they need to be more independent, you are probably better off gathering them manually. You could do something like: GLOBAL GatherFlag1 = 0 GLOBAL GatherFlag2 = 0 GLOBAL MaxItems1 = 4000 GLOBAL MaxItems2 = 3000 GLOBAL Offset = 10 GLOBAL NumItems1 = 2 GLOBAL NumItems2 = 3 GLOBAL Index1 = 0 GLOBAL Index2 = 0 OPEN PLC 0 //This will run at the RTI; you could also do the same as User-Written Servo/Phase Algorithm in C and run it at Servo/Phase LOCAL Temp If(GatherFlag1 == 1) { Temp = Index1 + Offset Sys.Fdata[Temp] = <<First Item to Gather>> Index1 = Index1+1 Temp = Index1 + Offset Sys.Fdata[Temp] = <<Second Item to Gather>> Temp = MaxItems1 - NumItems1 IF(Index1 > Temp) //Maximum before reaching end of Gather 1's Range { Index1 = 0 // Roll Over back to 0 } ELSE { Index1 = Index1+1 } } If(GatherFlag2== 1) { Temp = Index2 + MaxItems1 + Offset Sys.Fdata[Temp] = <<First Item to Gather>> Index2 = Index2+1 Temp = Index2 + MaxItems1 + Offset Sys.Fdata[Temp] = <<Second Item to Gather>> Index2 = Index2+1 Temp = Index2 + MaxItems1 + Offset Sys.Fdata[Temp] = <<Third Item to Gather>> Temp = MaxItems2 - NumItems2 IF(Index2 > Temp) //Maximum before reaching end of Gather 2's Range { Index2 = 0 // Roll Over back to 0 } ELSE { Index2 = Index2+1 } } CLOSE

I'd agree with Dave--I always try to split my troubleshooting for stuff like this into pieces. Rather than using a C PLC, which brings with it it's own set of questions (Did it generate an error on build and I didn't notice? Is it actually enabled? Are the pointers correct? Etc.), start basic. -If you issue the specific command to turn an output on through the terminal window, does the LED indicator turn on? -Can you turn them all on (GpioData[0] = $FFFF0000)? -After that, can you turn them off? As he noted in the previous post, 9/18/27 are inputs--you'll need to bring in the reference voltage into those pins. If you see the LEDs toggle, but aren't seeing your devices toggle, that's a likely cause. Finally, I'd check if your code was loaded properly and actually running.

Moving this to the Power PMAC forum, as I believe this is on a CK3M or other Power PMAC. If this is a Turbo PMAC, let me know and we can instead move this to the Turbo PMAC forum.

Moving this to the Power PMAC forum

I do not believe this topic is related to Code Reading, however this sounds like more of a technical support issue altogether. Please reach out to Omron Technical Support and they may be able to assist you more easily. If you are based in the US, this can be done by phone by calling 1 (800) 556-6766 or by email to ia.techsupport@omron.com.

I am not sure what your "standard procedure" was, so I can't really comment on what specifically needs to be done differently. Telnet on all current production versions of Power PMAC is disabled on the factory image, as it is not considered “secure” communication. Re-enabling this is a “Linux task” and would be outside of the scope of technical support. Also, note that the Linux commands to execute this could “brick” the firmware easily if done incorrectly. Use “SSH” communications instead (fully supported in the PDK and IDE). That said, please see attached for our generally recommended procedure. Enabling or Disabling Telnet on Power PMAC.pdf

Interestingly, another thread about this error popped up a few weeks ago. 1. Can you share what firmware version you're using? 2. Are you using any cutter compensation features, as mentioned in that thread?

@Sanjay_RSS, can you share what firmware version you're using?

To add on a tiny bit-- While it is allowed, it is generally considered bad practice to have short words like that (reset, status, etc.) as #defines or variable names. Any string which is either a command or part of a command (for instance, a variable named "AbsPos" would be considered part of Motor[x].AbsPosSf) should be avoided. A better option would be to name your parameter "ResetVar" if it is a variable or "_reset" if it is not. This way it is similar, but unique.

That's actually a topic we've gone back and forth on a few times over the years. Disabling it will not impact any functionality of our software--it only matters if a user intends to use it for their own purposes (a custom HMI, etc.). We initially had it, then (I believe) disabled it by default for a while for security concerns, then enough customers wanted it on by default that we re-enabled it, and I believe the plan is a future firmware update (mainly focused on security) will be disabling it again. Please see the attached document. Know that at this time, all Power PMAC products are on Debian 8, however we decided to expand the document a bit to pre-emptively "future-proof" it. Enabling or Disabling Telnet on Power PMAC.pdf

There is! I'm attaching an app note. In short, if you issue the "gather" command at the Linux prompt, it will effectively tap into the data being gathered and stream it to your terminal. If you'd prefer, you could even map the host computer as a network drive on your PMAC and then directly write to a file on it. Advanced Data Gathering on Power PMAC.pdf

Not directly from a UMAC--there are analog input/output modules, but I don't think anything that designed to work with a thermistor. I suppose with a 59E3, you could output a small voltage/current across it, then measure the resulting voltage drop, but it's not something I've done before myself. If your UMAC has EtherCAT, you could use an NX-TS module in conjunction with an EtherCAT Coupler for a simpler solution.

I've flagged to the web team that the CK3C manual seems to have been missed--it does exist, though. That said, the EQU signal on the CK3C should not be different from any other Power PMAC--it is still 5V TTL, and the Gate3 itself should handle the rollover. CK3C User's Manual.pdf

Just to add on a tiny bit, to explain the table Greg shared but in picture form... If the data PMAC is receiving is simply shifted, such that 0V corresponds with an ECAT[i].IO[j].Data value of 32k, then the data would look like this: However, it is also possible that the data is coming across in the incorrect data type--the device is sending signed data, but PMAC is reading it as unsigned data. In that case, 0V would correspond with ECAT[i].IO[j].Data having a value of 0, and it would "track" up to the value of 32767. However, what PMAC interprets as the most significant bit would actually be a sign bit, so any negative value sent by the device, PMAC would interpret as 32768 or greater. In this case, the data would look like this: To correct this case, you would have to compensate for the incorrect ESI file provided by the manufacturer and "trick" PMAC to reading the data as being signed. The easiest way to do this is to make use of Sys.nData[x] (such as .IData or .Udata in this case) to read the data as a different type than what PMAC originally believed.

To expand a little bit on the "purpose" for that file-- If users use the "System" folder of their project to configure their system (clocks, motors, etc.), when users perform a download, the IDE will first take all of the settings from that folder and compile them into "systemsetup.cfg". Because of this, like Steve said--if you aren't using the "System" folder, but instead using the older method of configuring things with files in Global Includes or manually loading a Configuration file, you should set the file to not download.