>
> Chris or anyone else, do you have hardware to test this on, particularly
> hardware from a different vendor than the Siemens PLC that Dave tested?
> I have an Arduino with FreeMODBUS firmware and may be able to
> temporarily use an Automation Direct VFD. (I was able to use function 4
> on the Arduino in classicladder before Dave's modifications; I haven't
> tried with the patch, or any functions besides 4)
I have a VFD and a modbus slave simulator for pc.
I also used a usb to serial converter (for the slave simulator side)
I will try to get to this this weekend (no promises )
>
> Before I get in to my remarks about the proposed patch, I want to thank
> Dave for doing the work and sharing the results of that work. He fixes
> important bugs and I want to make a big deal out of things like where he
> adds spaces! But code organization really is important -- probably the
> idiosyncratic way that much of classicladder is written was tough for
> Dave to understand the first time (I know it has been for me as I read
> the existing code while reviewing this patch). We can improve this over
> time, but only by holding new submissions to a higher standard than is
> seen in the existing code.
I thank Dave too!
Of course some of the bad coding practice come from me.
Classicladder was my first use of C and realizing what was good coding
practice is part of the learning curve. I am still learning.
When the code is finalized I will pass it to Marc (CL's originator)
>
> > Because I removed all hard coded timers, the Modbus Com thread can now
> > put significant load on the CPU if run without either a delay after
> > transmit or an inter transaction delay.
>
> This is particularly worrisome to me. This means you're busy-waiting,
> and you've identified the consequence of it. I didn't see what part of
> your patch busy-waits but it must be there.
>
One workaround is to default the pause-after-receive time to a fairly
large number so the out-of-the-box cpu loading is light.
> Next, 0x8, Diagnostics. According to the documentation I am reading,
> the response consists of
> 1 byte - function code (0x8)
> 2 bytes - subfunction code
> ? bytes - data (depends on subfunction and data in request)
> therefore, I don't believe it is possible to calculate the number of
> bytes in a diagnostics reply PDU based only on the function code and
> number of elements. I also don't see an opportunity to send a
> Diagnostics request in classicladder. Did your testing cover any
> MODBUS_FC_DIAGNOSTICS requests?
>
CL's diagonostics was hard coded to subfunction 0 - echo data.
the data was hardcoded as 257
CL would just check to see if 257 was returned or not.
You could send a request by clicking 'slave echo'
Marc did this differently I just can't remember how at the moment..
Though I do believe you could choose the subfunction.
Chris M
_________________________________________________________________
Turn down-time into play-time with Messenger games
http://go.microsoft.com/?linkid=9734385------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
