Hello,
we switched our development to Profinet (from previous profibus) and managed to have a configured profinet slave that works with your example (the speed_example) driver implementation.
At this point the cyclic data is exchanged and it works, but we need to implement also non-cyclic data exchange.
How can I handle non-cyclic read/write requests from the profinet in your driver?
Hello,
What is the Anbyus unit that you are using?
Hello,
it is an NP40 Anybus profinet module.
I am in a similar situation to Merlin. It was fairly easy to modify the speed example host so that the cyclic process data resembles what my application calls for. It is not obvious how to add acyclic configuration data to the host. Is this going to require protocol-specific code to implement or is there a generic way to define this as there is with cyclic process data?
From what I saw, I am able to access ADI already mapped to cyclical frame as if they were acyclic.
I mean, in the speed example I am able from the beginning (without modifying anything) to access in an ACICLIC way the speed and speed_ref parameters. (Unluckily I have problems writing the speed-ref in acyclic way but maybe it’s a problem of my controller, not the HMS slave)
If instead I want to define parameters that need to be accessed ONLY in acyclic way I have to add them to the ADI table with options that don’t map it (see in the #define section, you will find some attribute that don’t map the variable but only give SET or GET access).
At that point you don’t have to insert anything more in the map table (obviously this new parameters shouldn’t be mapped to the process data) and you can access them in acyclic way.
I found some troubles with index moduble and submodule, but anyway they should be the ADI number if I remember well.
Still I have problems writing them from my controller… if anyone knows a simple and free controller using a PC network card to just test profinet acyclic communication please tell me…
(I tried using Twincat and succeded in cyclic communication, but acyclic with twincat profinet IO controller is a mistery to me :D)
Hello,
Mapped ADI’s are accessible via both cyclic and acyclic requests. If an ADI is not mapped it will only be accessible acyclicly via read/write record data requests.
The Speed example might not be the best one example for you to look at. It might be to basic. The separate16 might be a better example to take a look at since this also has data not mapped to process data. It also uses the ABCC_CFG_ADI_GET_SET_CALLBACK which is needed to handle the requests. This is missing from the speed example and might be why you are seeing issues.
Deryck
Deryck,
Are you saying that the ADI #12, the one which is not mapped, is acyclic data that the PROFINET controller can write to?
I do not see how it is referenced in the ‘GSDML-V2.34-HMS-CompactCom 40 ADIMAP_SEPARATE_16-20191121.xml’ file. Does this need to be edited so that the controller will know about it?
Yes the ADI is not included in the GSDML and would need to be updated to include this adi.
I believe our GSDML tool was used to create the GSD file and since the ADI did not have ABP_APPD_DESCR_MAPPABLE_WRITE_PD and/or ABP_APPD_DESCR_MAPPABLE_WRITE_PD it was not added. If this was added we should see it in the GSD.
Deryck
Ok, I’m trying to do a write with acyclic communication,
after issuing this command:
I tried to debug the HMS stack and finally ended here:
My ADI table and map are these:
const AD_AdiEntryType APPL_asAdiEntryList[] =
{
{ 0x1, “SPEED”, ABP_UINT16, 1, APPL_WRITE_MAP_READ_ACCESS_DESC, { { &appl_iSpeed, &appl_sUint16Prop } } },
{ 0x2, “REF_SPEED”, ABP_UINT16, 1, APPL_READ_MAP_WRITE_ACCESS_DESC, { { &appl_iRefSpeed, &appl_sUint16Prop } } },
{ 0x3, “TEST”, ABP_UINT16, 1, APPL_NOT_MAP_WRITE_ACCESS_DESC, { { &appl_test, &appl_sUint16Prop } } }
};
/*------------------------------------------------------------------------------
** Map all adi:s in both directions
**------------------------------------------------------------------------------
** 1. AD instance | 2. Direction | 3. Num elements | 4. Start index |
**------------------------------------------------------------------------------
*/
const AD_MapType APPL_asAdObjDefaultMap[] =
{
{ 1, PD_WRITE, AD_MAP_ALL_ELEM, 0 },
{ 2, PD_READ, AD_MAP_ALL_ELEM, 0 },
{ AD_MAP_END_ENTRY }
};
As you ADI number 3 is not mapped and set to write enable.
The strange thing is when I issue a read implicit command (0x5) instead I’m able to read that variable.
Code goes into this section:
So when reading it goes into ABP_CMD_GET_ATTR and then into ABP_APPD_IA_VALUE, and read works.
The command I use to read is this:
Why the write instead goes to not supported ?? How can I support that (Do you have an example) ?
Am I using a wrong command?
Is there a working aciclic write xample in you application example?
Thanks
Hello @Merlin,
It looks like you are not accessing the ADI. Refer to section 3.4.1 of the Profinet design guide.
You should be accessing slot 0, subslot 1, index 3. I am assuming record ID is the same as the index.
Ok, I inspected communication using wireshark and found this error:
In this case I’m trying to write the “ref-speed” adi using acyclic commands.
I attach you the wireshark log: error_write_acyclic.pcapng (90.0 KB)
To me the packet seems to be well formed (IMHO the API, slot/subslot are correct), but module answer with state error.
The strangest thing is that I cannot put a breakpoint in the driver to see what is happening, I mean, when issuing ACYCLIC READ command I’m able to step the program and see what’s happening. I see that AD_ProcObjectRequest() is called from ad_obj.c.
But with WRITE command it seems that ANybus module just gives an error and nothing more. (It seems that HMS driver don’t do anything related to that error). I’m not able to hit any breakpoint that is hit when issuing READ command.
Maybe the acyclic write command need to be somehow enabled in the HMS driver ?
Thank you.
Hello,
I don’t think the issue would be with you needed to enable Acyclic write but it could be an issue with the access to the object. Maybe the parameter is locked at the time for a Acyclic Write if you have a Cyclic Write. It doen’t make sense to be doing both at the same time since the Acyclic write would be over written almost immediately.
Try writing with an ADI that is not mapped using APPL_NOT_MAP_WRITE_ACCESS_DESC .
You are almost right, but I already tried to send an acyclic write on ADI 3 (see my previous post) with the same exact error result.
In particular I tried to deeply inspect your HMS driver in the point where spi_transfer take place between the firmware porting and the HMS module. (by the way my HMS anybus is using SPI interface to a TexasInstrument ARM micro).
In that point I found that acyclic READ are correctly recevied through spi, while acyclic WRITE seems to be never received by the firmware, but the module somehow is able to answer. It seems as the module is rejecting the frame before passing it to the firmware. Could it be possible? Do you know why?
Thanks
Another question that rises in my mind is this: the ADI #3 which I’m trying to write, should be present somehow is the GSDML file or not?
Hello again,
I probably finally managed to find the issue!
It was related to my master software “Port Device Configurator” that was sending Write Request with strange “sequence number” values.
Comparing the packets sent with another kind of master software (Proneta by Siemens) I noticed that Write Requests were going out with sequence number at 0 and they were working at least for IM paratemers.
So I crafted out by hand some frames with correct sequence number and injected them into the network device with my needed ADI numbers. The Anybus module finally answered OK and set the ADI.
So for now this problem seems to be solved.
Then I have a new question: in Profinet there’s any diagnostic parameters that I need to enable in your HMS driver? Or it is already enabled by default? Where can I found these parameters to check the network status on the slave device?
Thank you.
It depends how the ADI is configured. If it is not mapped it will not be in the GSDML file.
There is a diagnostics object on the compactcom. This includes network specific errors.
Ok, thanks,
but on Profinet which is the diagnostic object? Where can I find information on it ?
Ok sorry, perhaps I understood: what you were meaning is that no additional work should be done in application software to add profinet diagnostic using HMS compactcom module, because diagnostic is already implemented in firmware? Could you confirm that ?
Thanks
I might not be understanding exactly what you are asking. The compactcom has a diagnostics object for handling profinet diagnostics. Have you looked at sections 4.6 in the profinet guide?
