TIA v15 ???

Allright, Siemens will present TIA v15

https://www.siemens.com/global/en/home/company/fairs-events/sps-ipc-drives.html

It's all about digitalisation and industry 4.0...

Will TIA 15 be completely different than TIA v15 ???

I've red that you could even program in C++ in v15 ???? WTF ??

Anyone knows what's coming ?

Thanks
G

Combo said:

Allright, Siemens will present TIA v15

https://www.siemens.com/global/en/home/company/fairs-events/sps-ipc-drives.html

It's all about digitalisation and industry 4.0...

Will TIA 15 be completely different than TIA v15 ???

I've red that you could even program in C++ in v15 ???? WTF ??

Anyone knows what's coming ?

Thanks
G

Click to expand...

Here is something about these PLC's that you should all understand and specifically relating to your statement about being able to program in C++. At the end of the day, all of these languages end up in machine code. Specific formats for instructions that are compatible with the specific hardware they are running on. That is a HUGE oversimplification, but it gets the point across.

The PLC programming software takes our LDR, STL, etc instructions and translates them, or rather "parses" them into whatever language the programmer of the IDE decided to use. This sort of process continues stepping down to lower levels until we have machine code that is specific to the controllers in our PLC's. So it really isn't a stretch that you can program in any language and achieve the same end result as long as you are aware of the caveats of the process you are using.

Anywho, more "IoT" stuff hehe. Here we go.

sparkie said:

Here is something about these PLC's that you should all understand and specifically relating to your statement about being able to program in C++. At the end of the day, all of these languages end up in machine code. Specific formats for instructions that are compatible with the specific hardware they are running on. That is a HUGE oversimplification, but it gets the point across.

The PLC programming software takes our LDR, STL, etc instructions and translates them, or rather "parses" them into whatever language the programmer of the IDE decided to use. This sort of process continues stepping down to lower levels until we have machine code that is specific to the controllers in our PLC's. So it really isn't a stretch that you can program in any language and achieve the same end result as long as you are aware of the caveats of the process you are using.

Anywho, more "IoT" stuff hehe. Here we go.

Click to expand...

You're preaching to the choir

Combo said:

Allright, Siemens will present TIA v15

https://www.siemens.com/global/en/home/company/fairs-events/sps-ipc-drives.html

It's all about digitalisation and industry 4.0...

Will TIA 15 be completely different than TIA v15 ???

I've red that you could even program in C++ in v15 ???? WTF ??

Anyone knows what's coming ?

Thanks
G

Click to expand...

I'm pretty sure V15 is just the next rev of Portal. There'll be some upgrades and some new stuff, but I doubt there will be anything earth shattering. They really ramped up the digitalization stuff in V14, but most of that stuff involves a complete re-imagining of the PLC workflow. It takes a special kind of crazy to be the guy who jumps on that trend early.

Regarding C++, I doubt that will be coming directly into portal. I know there is a 1518 ODK (different part number from regular 1518) right now where you can write C++ code outside Portal, and then have it compiled to run in the 1518. Your link mentioned a 1518MFP; I think that is supposed to kick it up a notch, but I don't know the details. Regardless, my guess is that it will continue to be a special product for a niche market.

It's possible that Portal will start to see some more object oriented type concepts coming, though (to the languages it already has). IEC 61136-3 got an update a few years ago to include some new features like methods and class inheritance. I think the Codesys type packages support it. I can't imagine the Germans would pass up an opportunity to include even more ways to complicate the programming, so i figure these will show up sooner or later....

My big hope is to get some upgrades to the multi-user server. I'd love a real change log like PC programmers can get from something like git or subversion, but I'd settle for simply auto-marking my changes.

mk42 said:

I can't imagine the Germans would pass up an opportunity to include even more ways to complicate the programming, so i figure these will show up sooner or later....

Click to expand...

This is an unfair comment or from someone that never really understood the Siemens intended workflow.

As is now you can already encapsulate functionality and use it that way, having the possibility to extend that is even better as you could have a high level valve object and you can then write the different bits for the valve in question.
This is kind of achievable today in Siemens but not with the bells and whistles. Similarly, you can achieve quite a few of the things C++ does in C, but it's not clear for all and certainly will look confusing instead of logic.

Siemens already had (like 20 years ago), a processor that could be programmed in C/C++, the M7. So it's not exactly something new... what is different today is that processors have a huge amount of horsepower comparatively and there are more people learning to program text languages than there are picking up on PLCs.
Obviously, it is completely different to program a desktop application or an industrial control application in C, but someone that focused on microcontrollers/microprocessors can easily program a PLC that way.

I would think it will be like STL and Ladder, the CPU will be running same/both but you can change the view to see either one, I just hope its not like the S5's that were programmed in STL can not be viewed in Ladder

I am sure there will be some function that you can not change over but from what Combo's link its all about Teamwork

Go Team GO!

geniusintraining said:

I just hope its not like the S5's that were programmed in STL can not be viewed in Ladder

Click to expand...

S7 is the same for most sane people...
I'm yet to find someone that writes code in STL that can be converted to Ladder unless it is very, very basic.

cardosocea said:

S7 is the same for most sane people...
I'm yet to find someone that writes code in STL that can be converted to Ladder unless it is very, very basic.

Click to expand...

I have to 2nd cardosocea here; LAD goes to STL and back, but something written in STL almost never goes to LAD.

I don't think there is any chance that the C/C++ code will be editable in Portal in any significant way. First of all, they mention that it is only for the "Multifunction Platform" addition, which is probably new HW (they already mentioned a 1518MFP on another site). Second, they mention third party editors (Eclipse). My understanding of the process for the existing tools is that when you write ODK functions, you write it in eclipse, and when Eclipse compiles the code it creates 2 files. One is an SCL source you can import so that Portal has the block interface. The other is an object file that has to be transferred over to the CPU manually (I think via the web interface?).

geniusintraining said:

I just hope its not like the S5's that were programmed in STL can not be viewed in Ladder
Go Team GO!

Click to expand...

I think for s5 catering to people who prefer LAD was definitely not at the top of their list. I have found it extremely difficult even trying to program in ladder. I usually just write the code in STL and then change the view to LAD to verify the result, which tells you whatever I'm doing is simple, because otherwise it wouldn't convert.

cardosocea said:

This is an unfair comment or from someone that never really understood the Siemens intended workflow.

As is now you can already encapsulate functionality and use it that way[snip]

Click to expand...

Unfair, maybe. Written by someone who was a little grumpy just before bed, almost certainly.

However, Siemens is my main workhorse, and I'd like to think I understand the intended workflow. My comment was 50% serious, 50% in jest.

The reality that I face in the US is that if I write code that a high school dropout can't understand without additional training, my customers won't accept it. This usually translates to: turn the Siemens intended workflow on its head, and make an S7 pretend it is a Logix. It is stupid, and it wastes so much potential on the S7 side, but it is what my customers expect time and time again. I've seen cases where someone got burned using an AOI years ago, so they won't let me use FBs.

mk42 said:

The reality that I face in the US is that if I write code that a high school dropout can't understand without additional training, my customers won't accept it. This usually translates to: turn the Siemens intended workflow on its head, and make an S7 pretend it is a Logix. It is stupid, and it wastes so much potential on the S7 side, but it is what my customers expect time and time again. I've seen cases where someone got burned using an AOI years ago, so they won't let me use FBs.

Click to expand...

In fairness, FB's are a tad more flexible than AOIs.
Why would someone go with a "exotic" brand in the US and then not take full advantage of its capabilities?

cardosocea said:

Why would someone go with a "exotic" brand in the US and then not take full advantage of its capabilities?

Click to expand...

Exotic? I have called a PLC a LOT of things (most are banned from the site) but exotic has never been one

cardosocea said:

In fairness, FB's are a tad more flexible than AOIs.
Why would someone go with a "exotic" brand in the US and then not take full advantage of its capabilities?

Click to expand...

I don't have any good reasons that it's done, I just have the ones people give me. I think it's an idiotic practice. If you're going to switch to a new system because you like it, maybe you should actually utilize the advantages that made you like it?

Reason 1 is usually some combination of diversity/keeping the players honest. Facilities are often going multi spec, with multiple PLC brands in play. I've seen situations where a new/retrofitted facility was split in half. Same process on both sides, but one integrator using AB and one integrator is using Siemens, but has mostly AB trained guys. In theory, forces the integrators to play fair, forces the component vendors to play fair; in practice it's a mess.

Reason 2 (following from reason 1) is "we want the same code no matter what PLC platform we use". Understandable from a maintenance point of view, I guess, but it means you're either essentially stuck with the lowest common denominator or you have to bend a system backwards to make it act like the one you really wish you were still using.

You become an engineer so you don't have to deal with politics and interpersonal junk, and then find out that it's worse now because everyone else was hoping the same thing....

mk42 said:

The reality that I face in the US is that if I write code that a high school dropout can't understand without additional training, my customers won't accept it.

Click to expand...

Amen!