DeviceNet: Uploading vs. downloading. Issues with Yaskawa Drive

AutomationTechBrian

Lifetime Supporting Member
Join Date
Jul 2013
Location
St. Cloud, MN
Posts
669
I've been struggling with adding a Yaskawa drive to an existing DeviceNet network. I installed a new Yaskawa drive and programmed the drive, changing the usual parameters to match the motor and the use.

Then I installed a SI-N3 card, downloaded the EDS sheet from the Yaskawa website and registered the drive and EDS file on the network. (Node 22)

When you click on properties for the drive, you have to choose to either upload from or download to the drive. Well... since I've already programmed the drive, I always choose to upload from the device. This is where the issue comes in.

There are some minor errors that come up that are noted, but that do not stop the uploading... but then a major error stops the upload. I am working with Yaskawa to fix the EDS issue, but I'm now on my 3rd EDS file, and I still have issues. Here is a copy of the errors that currently come up:

**********************
Address 22: An invalid value has been uploaded for Param2. The parameter's default value (as specified in the EDS file will be used.)

Same for Param3

Address 22: Communication Error(0xC) 'Error response recieved: Attribute not supported.', SCIA(0xE, 0xC7, 0x0, 0x66), Param389.

**********************

This is getting frustrating, so I curious if I'm there's another way to make this work.

Here's my question for those with more experience with DeviceNet: Would you keep working with Yaskawa to perfect the EDS file, or would you try *downloading* to the drive, then try reprogramming the parameters. I don't even know if it would work to download... maybe the same errors would come up. I would love to get beyond this problem, but don't want to waste time or make things worse.

Thanks!
Brian
 
Attempting to download might make things worse. I wouldn't do it.

Can you post your current EDS file so we can look at each Parameter ?
 
My next recommendation is going to be to "peek" a the raw value for Parameters 2 and 3, and compare that to the acceptable range according to the EDS.

Right-click on the Yaskawa interface in RSNetworx and choose the "Class Instance Attribute Editor". This gives you the ability to send raw DeviceNet explicit messages.

What you need to send is Service Code = "Get Attribute Single", aimed at Class 0xC7, Instance 0x03, Attribute 0xC3 and 0xC4.

Those messages should return the values of Attribute 0xC3 (Parameter 2) and 0xC4 (Parameter 3).

And that leads me to the probable problem with those:

The EDS says that Parameter 2 should be between 20 and 21, but that the default is 126.

For Parameter 3, the range is between 70 and 71, but the default is 199.

You see the problem.... the default value is out of the max/min range. That's what RSNetworx is choking on.

I don't think that having a default out of the max/min range would have passed any sort of conformance or compatibilty check, but it's where we are.

The simple fix is to change the maximum value in the EDS for both parameters, then re-register the EDS.
 
The issue with the "Attribute not supported" might be more difficult. I'll have to see the actual EDS you are using, since there are dozens and the one I chose out of the folder confuses me about Parameter 389.

SCIA(0xE, 0xC7, 0x0, 0x66), Param389

Class 0xC7 is the parameter class for this drive.

Instance 0x04 should be most of the Parameters, not Instance 0x00. There may be a typo in the EDS that explains this.

The Attribute numbers don't line up exactly with the Parameter numbers. In fact, they're all over the place. We'll just have to see the EDS itself.

My experience with Yaskawa and various open networks is that they are pretty good about helping out if you're willing to help problem-solve.
 
Before I attach the file, I want to double-check everything and make sure the new file truly got registered, and not version #2. The electrician also has a quick issue for me to help him with...

Be back soon.

Brian
 
Param389= $U1-19
0,
6,"20 7D 24 00 30 66",
0x0030,
0xC7,
2,
"U1-19:Memobus Error Code",
"",
"",
0,65535,0,
,,,,
,,,,
;

The string of hex values in quotes is the Class / Instance / Attribute codes. This means that Parameter 389 is Class 0x7D, Instance 0x00, Attribute 0x66.

All the other parameters of the group "U1-xx" in the surrounding parts of the EDS are called out as Instance 0x01, not Instance 0x00.

It's worth a try to manually edit the EDS to set the Instance byte to 0x01 (so the whole thing is "20 7D 24 01 30 66"), re-register the EDS, and try uploading again.

Only Yaskawa can say for sure if that's the correct Class/Instance/Attribute data for that particular parameter, but it's a most likely candidate.

Alternately, if you don't care about that Memobus error code, just comment out that Param389 section with "$" characters (see the beginning of the EDS for the syntax of using $ to designate comment text).
 
It worked! Thank you so much, Ken! I also enjoyed seeing the workings of the file.

Now I get to write Yaskawa... "nevermind, there was a small error in the string of hex values..."

Next, I'll give a shot at writing the values I need into the PLC. I felt confident about the process two weeks ago. How much can a guy forget in two weeks???

Thanks again,

Brian
 
Ken Roach said:
The EDS says that Parameter 2 should be between 20 and 21, but that the default is 126.

For Parameter 3, the range is between 70 and 71, but the default is 199.

Ken,

That was well spotted on the Instance 0x00. (y)

Just one thing that I wanted to point out though with regard to EDS file parameter ranges and how you were reading them.
The parameter range and default values for a standard EDS file are read as Min, Max, Default, and not Min, Default, Max.
It's an easy mistake to make when an EDS file is not commented.

So in this case...

Param 2 = 20, 126, 21 - Range = 20 - 126, default = 21

Param 3 = 70, 199, 71 - Range = 70 - 199, default = 71

Which would make them inside their respective ranges.

Brian,

I'm sure you only had to edit the Instance number to solve this problem, and didn't have to touch Param 2 & 3?

Interestingly, I downloaded a zipped folder of all the EDS files for the SI-N3 from the Yaskawa website, as I think Ken did? When you attached the current EDS file you were trying, I noticed it was dated 2010. The equivalent EDS in the ZIP I got is dated 2013 and has the U1-19 Param set to Instance 0x01. Looks like it was just a typo in the versions you've been trying?

The 2013 version also has 753 parameters for the same drive compared to 391 in the 2010 version.

Might be important if you run into other issues.

Attached is also an example from an AB Drive EDS file that has comments.

G.

Param_Range.PNG
 
Ahhh... don't go away, guys. I'm not home-free yet! And yes, I'm staying late for this one. It's 9pm here.

Btw... the file I attached is a revision I had emailed to me directly from a Yaskawa Applications person. The file on the website is a prior file that didn't work when I downloaded and registered it.

Parameters 2 and 3... They were the selection for the PPA and PCA values. You can choose the "package" of values that are mapped into the I/O of the scanner. The default values didn't match the values I needed in the PLC Ladder files, so I changed them from the selection in the I/O section of the drive preferences in RSLogix. HOWEVER... They evidently *really* want to see the default size used. When I manually changed the size to match the "package" size, I got a warning. And after I finished mapping the I/O in the scanner, I got a code 77 error on the DeviceNet Card.

I copied and some windows to give you a visual of what I'm talking about. I see there is an area at the top of the EDS file where it talks about the polled I/O characteristics...

$ ***************************************************************************
$ I/O Characteristics Section
$ ***************************************************************************
[IO_Info]
Default = 0x0001;

PollInfo =
0x0001,
2,
2;

I'm assuming this is what is screwing things up, but I can only guess what the values would be to fix it.

Take a look at the attachments and let me know if the issue is clear. I have 6 attachments and it looks like I can only do 5 per post. I'll probably attach the last one after this post.

Thanks!

Brian

InputMap.jpg I-O_Data.jpg Polled_Input_and_output_changes.jpg PPA_PCA_Values.jpg Scanner_Config_Warning.jpg
 
And here is the last attachment from the manual.

The PCA is the same size as the default, so I suspect it's not an issue. I admit, I'm a little fuzzy about the bytes versus the map size. I looked at what was already there and applied some logic about what settings to use.

TechManual_PPA_Choice.jpg
 
Oh, and while we're at it...

High byte and Low byte... would the difference be the decimal point?? Example: 443.8 amps... 443 would be the high byte and 8 the low??
 

Similar Topics

Hi I'm new to Allen Bradly. I've managed to uploaded the PLC code, but need to diagnose the devicenet card. How do I upload the configuration so I...
Replies
6
Views
1,828
I have a client with 7 lines of conveyors which each have up to 30 Powerflex 40 drives on DeviceNet. I have vpn access to the site and am trying...
Replies
1
Views
3,069
We've run into an old system that we are upgrading which is still running Steeplechase with Citect using Devicenet to Wago. I had some experience...
Replies
4
Views
135
Sigh, DeviceNet noob... I have a 1756-L55, with a DeviceNet module, and 10 PF700 all commanded with DeviceNet. One of the PF700's blew up...
Replies
3
Views
128
Good day Forum Members I got a older Lincoln welder and hoping to make it work at our shop. Welder in question is the Lincoln Power Wave 455M...
Replies
4
Views
190
Back
Top Bottom