Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

Micromaster 440 not seeing command data over profibus

Created by: Kevin Jones at: 11/14/2009 2:36 PM (8 Replies)

Rating (0)

Thanks 0

9 Entries

11/14/2009 2:36 PM	Rate (0)
Kevin Jones Posts: 9 Rating: (0)	I'm using Rockwell RSLogix PLC with a Prosoft MV56 profibus card to communicate with a network of SIMOCODES and 3 Micromaster 440 drives. The SIMOCODES work fine, but I'm having problems with the drives. I'm reading the status word from the frive fine if I start it unsing the terminals, but my command word data doesn't seem to be turning up in the drive. Looking at the expert list using the STARTER utility, I can see parameters that are the "received word 0,1,2,3" etc from the CB. This shows values that do not reflect what I am sending it. It seems to be that when the drive is first switched on, it kind of half works, but then faults and doesn't update the data any more. My belief (although it may well be wrong) is that the profibus command data should appear in the drive even if the drive chooses to do nothing with it. I've checked in the CB status parameters, and they say that it's profibus and cyclic data exchange is going on. Any ideas? Sorry I can't add more details - the network went down on-site, so I'm writing this from memory at home. Many thanks, Kevin Jones
Kevin Jones Posts: 9 Rating: (0)
Suggestion To thank Quote Answer

11/14/2009 7:37 PM	Rate (0)
Graeme Platinum Expert Joined: 6/4/2008 Last visit: 11/25/2025 Posts: 1521 Rating: (327)	Hi Kevin, I have encountered a similar situation in the past due to the different ways in which Siemens and Rockwell structure their data words. For example, in a Siemens system, the bytes are "logically" numbered as follows: WORD 1 WORD 2 etc --------------------------------/\----------------------------------- \| ---------------------/\ / \ BYTE 0 BYTE 1 ---------------/\-------------- ---------------/\-------------- / \ / \ b15 b8 \| b7 b0 So as you can see, Bit 0 of Byte 1 is actually Bit 0 of Word 1, and Bit 0 of Byte 0 is actually Bit 8 of Word 1. Check the byte order of the profibus word you are transmitting. I had to work the other way, sending data to a Rockwell SLC, I had to use the CAW command to byte swap so the Rockwell PLC could interpret correctly what I was transmitting. Hope this makes sense. Graeme

Suggestion To thank Quote Answer

11/14/2009 8:43 PM	Rate (0)
Kevin Jones Posts: 9 Rating: (0)	Thanks for your reply Graeme. I am indeed familiar with problems with byte order when converting to words on different machines. What I've done in the past is set the bytes in the PLC to different values and watch how they map through to the other end. I've also checked the byte order on the reads from the drive (Surely Siemens wouldn't be evil enough to have different byte orders for read and writes would they?) The problem I have is that I can't find the data arriving on the drive anywhere. I can read it from the drive and I can write to the Simocodes in the correct byte order, but I can't find my commands anywhere on the drive. I'll try and post some more specifics tomorrow assuming the network's back up. Kevin
Kevin Jones Posts: 9 Rating: (0)
Suggestion To thank Quote Answer

11/14/2009 10:48 PM	Rate (0)
mumbles Posts: 160 Rating: (16)	Hi Kevin, Do you have bit 10 set in control word 1. If not then the drive will not accept the control data as it deems it to be invalid. The status data will still work as you have seen.
mumbles Posts: 160 Rating: (16)
Suggestion To thank Quote Answer

11/15/2009 3:23 AM	Rate (0)
Kevin Jones Posts: 9 Rating: (0)	Hi mumbles. That could well bw it. I'vebeen setting bytes to -1 (all bits set), seeing it do something, then setting them to 0. This would obviously meant that bit 10 wasn't set, so it effectively wouldn't accept the 0 if I understand what you've just said. I'll try it when I get in. Many thanks, Kevin Jones
Kevin Jones Posts: 9 Rating: (0)
Suggestion To thank Quote Answer

11/15/2009 11:54 PM	Rate (0)
mumbles Posts: 160 Rating: (16)	Thats correct. If bit 10 is not set then all control data (not just control word 1)are set to 0. I am sure you will find that this is your problem.
mumbles Posts: 160 Rating: (16)
Suggestion To thank Quote Answer

11/17/2009 10:09 AM	Rate (0)
Kevin Jones Posts: 9 Rating: (0)	Thanks mumbles, that was exactly right. I now have it working. I now only have to work out how the current is ranged when it's passed back as a parameter. (separate thread starting soon). Thanks again. Kevin Jones
Kevin Jones Posts: 9 Rating: (0)
Suggestion To thank Quote Answer

11/17/2009 11:02 PM	Rate (0)
mumbles Posts: 160 Rating: (16)	Hi Kevin, Are you referring to reading the current via PZD (Process Data) or by PKW (Parameter Data). If it is PZD then it will be scaled as 16384 = 100%. If it is PKW then it will be read as it is displayed in the drive. For example if you are reading r27 and it is displaying 10A on the display then you will read 10. The only thing you need to be aware of here is the decimal points.
mumbles Posts: 160 Rating: (16)
Suggestion To thank Quote Answer

11/18/2009 7:43 AM	Rate (0)
Kevin Jones Posts: 9 Rating: (0)	I'm reading it as a PZD and that scaling works a treat. Thanks, Kevin Jones
Kevin Jones Posts: 9 Rating: (0)
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on