But what is your application?
Also remember, 1500H doesn’t support TO’s.
The application is a high precision servo system. What are TO's?
Anyways, with Trace you can have limited samples, while with iba basically you can have unlimited.
Is this a different issue than the one JRW advised to use the "Automatically repeat recording" setting for?
Yes. You can change the actual values of tags in DBs while monitoring, via a watch table, or possibly from the DB editor. Or obviously from an HMI. Watch table is often the easiest way.
So then you have to make the watch table first. Just a little bit more mouse and keyboard work than ideal.
There is a new snapshot feature that allows you to take the current values in a DB and save them to be the offline start value in your program.
New? Is it any different from saving DB actual values from online, to the offline project in Classic?
I've only ever heard of MRPD used in conjunction with IRT, so I can't imagine it would support it before IRT support is available. I'd be shocked if it IRT support arrived without MRPD.
I haven't worked with either before, but from what I've been able to research, MRPD is just for the bumpless redundancy, by sending all telegrams in both directions on the ring. That way, even in case of a cable break, there are no lost telegrams. And MRPD is required by IRT. So MRPD = cool, and should work by itself, but perhaps there's no need for it for other things than isochronous real-time applications...
Siemens says they have customer references that say development was 33% faster in Portal than Simatic Manager. I dunno how much I think that is typical, but I definitely prefer Portal, once I got used to it.
I'm sure they do. And they sell Portal very hard. Whenever someone tries to sell me something really hard, I wonder how bad it really is. Kinda like when someone repeatedly demands that you trust them.....
There's definitely a hump for the 1st project, learning how the 1500s are different from the 300/400s. IF you adapt to the new way of using them, then you'll be fine. If you try to use them like they were still a 300/400, then you'll struggle.
FWIW, it is strongly recommended to avoid STL for the 1500 in any case. It is way slower now, and is pretty much only around for legacy migrations. The recommendation is to use SCL instead, but most things you used to need STL for can be done in LAD now.
Yeah, I read the programming guidelines for 1200/1500. My two key take-home points were: only use optimized DB's and symbolic addressing. I will add "avoid STL" to the list.
(bummer. I really liked pushing and popping, getting the code down to the least number of lines. Anyone wanting easy to read code must have hated me for it
)
Anyway, your advice is worth a lot. And makes sense, since they built the 1200/1500's on CPU's without the registers that STL is made for. I can't stand LAD btw, but I guess the compiler handles FBD just as well.
And what I really liked with STL was how you knew exactly what was happening at each line of code. Can't imagine SCL gives you the same control?