Hello, I’m trying to figure out what variable type in my C++ program should I use to read analog inputs of AXL F AI2 AO2 1H into. I’ve noticed a similar question already asked here recently, and the recommendation there was to use signed int16_t. Unfortunately, when I use this data type, Eclipse refuses to build with following error message: The data type ‘int16_t’ is not known. For ports and port structures only known data types can be used. When I try to use int16, it compiles successfully, but when I import the library into PLCnext Engineer 2020.0, I can’t use those variables as IN Port for analog inputs - they are not on the list of IN Ports. Using data type int32 for port variables work for Bitstring16 inputs, and I can map them as IN Ports - but I’m not sure how should I read those values at the runtime. Also, additional issue, maybe unrelated - when I use boolean data type for the input ports of the digtal IO module (namely, AXL F DI8/1 DO8/1 1H) and then connect them as IN Ports in PLCnext Engineer - everything works smoothly and I can see that variables values changes when running in debug mode and using the switch module of starter kit to change digital input values. However if I use uint8 variable and try to read from ~DI8 port, it works, but port value is only being read once, and is only updated when controller is rebooted. The program is being executed within idle task, so this could be the cause, but I still expect for port value to be updated, even if less frequently.
Hello, In that other case, the user was not declaring a Port variable, which it seems like you are trying to do. A list of C++ data types that can be declared as port variables is here: https://www.plcnext.help/te/PLCnext_Runtime/Available_data_types.htm In this table, you can see the Port types that can be matched with each other, in all languages. In your case, you want to match a C++ port to an analog input value of type Bitstring16 (you can see this type listed next to the Analog Input port in PLCnext Engineer). This is an FDCML type, and (in the table) you can see that a Bitstring16 can be matched to a C++ uint16 value. So, declaring your C++ variable as uint16 should solve the problem. Hope this helps. ~ Martin.
For the second issue - you are correct, this is unrelated to the first. I am afraid that I cannot reproduce the error you are seeing. Below is a video showing that both the BOOL variable and a BYTE variable connected to the ports on the DI module get updated simultaneously. It does not matter that your program is executing in an Idle task - unless your PLC is heavily loaded, the Idle task should execute frequently.
Thanks for the data types table. Worked like a charm. As for the second issue - sorry for not making myself clear enough. Yes, when using internal variables and mapping them to ports, they are updated frequently and I’m able to see changes immediately in the debug mode. What I meant initially were the port variables defined in C++ program running on idle task, like below: //#port
//#attributes(Input)
//#name(emu_AI_1)
uint16 m_analogInput1; In my very basic C++ app, few such variables’ values are logged (also to Output.log file) and and sent to another machine via REST API. This is done in endless loop - once every 100 milliseconds, hence the use of idle task. Now, I can see the that C++ port variables are being populated with values - but it only happens on the first iteration. On all the subsequent iterations, variable’ values are the same - until the controller is rebooted. I tried also to create a local program in PLCnext Engineer and run it in cyclic task, mapping them to input ports and use those as input ports for the C++ program, but result is exactly the same: internal variables do update their value, while C++ ones don’t.
Hello, Without seeing your C++ code, it is difficult to diagnose the problem … but:
This is done in endless loop - once every 100 milliseconds
… makes me wonder if you have implemented a blocking loop in the “Execute” method of your C++ program, or perhaps in one of your C++ Component methods. If so, this will not work. None of these functions should contain blocking code, and if they do then that would explain what you are seeing. Can you describe exactly how you are implementing this endless loop? ~ Martin.